From: Roger Hanscom Date: Sat, 3 Nov 2018 18:56:59 -0700 Subject: VersaFloppy II To: Herb Johnson Hi Herb, I hope you remember me -- Roger Hanscom in Mount Vernon, Washington? You have provided great service with documentation sent to me in the past. I trust that you are doing well -- I love your Web site!! I've got a question about the VersaFloppy II. I have a pretty stock SDSystems set-up -- SBC-200, RAMdisk, and 64k SRAM card. Works great with CP/M 2.2. I also have two VFII cards, and I've been looking at some of the great software you are providing on your site -- particularly the Bruce Jones (I think that's right?) stuff. I was intrigued that he seemed to be able to get 3.5" drives working with the VFII, and I'd like to see if I can get one (or more!) 3.5" drives working too. I singled out his boot program (V2BOOT1.ASM) because it appears to be very simple. Just wanted to see if I could read the boot sector of a 3.5" drive. It doesn't work! When I run it (from CP/M 2.2) without modification, I get nothing (absolutely nothing -- it even appears not to select the drive). In looking at his code, he uses the complement of what my documentation says for the drive identifier information (gets written to port 63H). He uses 7EH to select the "A" drive (DSDD full size). I found that if I change that to 50H (what my documentation says to use), the activity LED on the drive comes on, and it sounds like something is happening in the drive ("click"), but still no data comes off the drive at all (looking at it with ZSID, it seems that it hangs up with the INIR). So what gives? Are there different versions of the VFII? One of my boards is marked rev. "P" (the one I've been working with), and the other is marked rev. "G". Both are 1795B cards. I'm assuming that since I'm using the SBC-200, the "phase mod." is not needed? I've got the drive hooked up with a 34-pin "twist" ribbon cable to the 34-pin connector on the VFII. Just curious if you know that it is possible to get 3.5" drives working with the VFII, and if so, what's the trick? - Roger nov 3 2018 Roger, of course I recall you. Glad you are still hanging in there, and working on vintage computers. I have not looked at Bruce Jones' code in some time. I suggest you work with 5.25-inch drives first, to confirm the operation of your two cards. Then see about those 3.5-inch drives. Remember, the 3.5-inch drives run at two rotation speeds, you have to get that right, and the data rates. Of course, you can test your 3.5-inch drives, if you have an older PC available to operate them. YOu said: " I've got the drive hooked up with a 34-pin "twist" ribbon cable to the 34-pin connector on the VFII. " *get rid of the twist*. That's an IBM PC convention. This is not an IBM PC. read about the PC's connections, to learn about how that "twist" works. It won't work with non-PC controllers, they don't "twist". Also, make sure your drives are "terminated" - the last drive at the end of the floppy cable must have a terminating resistor or what ever your 3.5 or 5.25 inch drives use. Also, you saw results with a particular I/O address for your boards. Read the docs on your boards to see how the I/O address is selected. Are there two versions of the board? It's late, but I believe both my Web page, and s100computers.com's Web page for the VF II, says "yes". I think I and JOhn MOnahan discussed that. But the difference as I recall is in the analog data section, not digital. YOu have both versions - compare the chips and PC traces. OK? I think that's enough to give you some leads. Let me know your results. Good luck! - Herb Nov 4 2018 You are 100% correct -- best to start with more known hardware (i.e. 5.25" drives). My 360k 5" drives are in sad shape *frown*. Going south on a regular basis, but I do have a few 5.25" HD drives (the 1.2 MB IBM footprint), so I tested one on my Cromemco box, and got it working jumpered up as an A: drive. I've had good success with them on the Cromemco controller (telling the system it is an 8", and with "ready" jumpered to ground). I got a copy of John's (Monahan) diagnostic from your Web site, and massaged it a bit to get it to work with my hardware configuration. It is a very nice piece of work! Thanks for making it available. The 5.25" drive started out working immediately using the "seek test". I had to ground "ready" again (tried it without, but that failed). I could also format a diskette with the diagnostic. That worked as well. The diagnostic offers a number of 8" formats. I started with a DSDD 512b sector one. BUT, when I used the option to do random read/write tests, I got sporadic read errors (always "record not found"). I spent quite a bit of time trying a number of the offered formats, and discovered that *ANY* double sided format would give read errors, but there were never any errors using single sided formats. I tried a number of different diskettes, even one of my expensive Dysan MD2HD ones. Same result. I suppose to be thorough I ought to try another drive? I'll do that in a bit. Probably won't help because even though the double sided formats gave read errors, they weren't always on the same side. They appeared to be random (with respect to side), so probably not a hardware problem? Oh, and I discovered (looking at John's diagnostic) that the drive select codes used in the Bruce Jones stuff are not correct for this (ver. "P") VFII. John uses the codes that I thought were correct from the documentation I have for the VFII. You might keep that in mind if others ask about the Bruce Jones software? Might be fine if one changes the select codes? One minor nit -- as I'm sure you're aware, all of the newer 3.5" floppy drives are hard jumpered (very difficult, and sometimes impossible, to change) to be "B" drives, so to make one of those drives look like an "A:" drive, you *have* to use a "twist" cable. Maybe that's the problem with trying to use one of these newer "B" drives on a VFII? They are too PC-centric, and will never work? As you say, spindle speed and transfer rates just not correct for older hardware? Anyway, you got me started. Even if I can't get double sided formats to work, I can probably salvage something? I'm a little disappointed, however, because the reason I'm doing this is to try to (eventually) substitute one of those Gotek floppy emulators for the real floppy (as I said, my floppies are dying at an alarming rate). Not certain that can be done if the VFII is picky about formats. We'll see. Thanks again! - Roger Nov 5 2018 > a few 5.25" HD drives (the 1.2 MB IBM footprint) You realize, the 1.4M 80-track drives, have a narrower gap in the read write head? they read and write, narrower tracks than the 40-track 5.25-inch drives. As a result - follow this carefully - if you take a diskette written with a 40-track drive, "reformat" it on an 80-track drive, it will not completely erase or rewrite the original wider tracks. http://www.retrotechnology.com/herbs_stuff/drive.html#thin Use a bulk-tape eraser device to completely "erase" a diskette, before reuse. "Bulk tape eraser" - my apologies, look it up on eBay for details. > My 360k 5" drives are in sad shape *frown*. Going south on a regular basis... Be sure to clean the drive heads. They clog up with magnetic pieces. those effectly short-out the magnetic field. Of course, heads do wear out, the epoxy coating wears through and then the magnetic poles are exposed, debris gets trapped, etc. Electronics drift, capacitors weaken, etc. Point being: it's good to have *known good drives* around for testing computers and controllers. And *clean, well-erased, diskettes of some quality* also for testing. Verbatum, Dysan, 3M, are good brands among others. Good lubricants and less likely to wear. > expensive Dysan MD2HD diskettes HD diskettes are not good for DD formatting. People refuse to believe that. But HD media has higher "coercivity" - takes more magnetic field - to write to than DD media. They are designed to work at 360 RPM, not 300 RPM. > all of the newer 3.5" floppy drives are hard jumpered (very difficult, and sometimes impossible, to change) to be "B" drives, so I forgot that. But the "twist" also changes another line I think. But the facts are: I don't put 3.5" drives on my 8" systems. I really don't keep track of people's attempts to replace 8" drives with 3.5" drives. Other people do that: they have WEb sites; ask them. (shrug). Roger, I'm sorry I have not got "down in the weeds" with your work on these drives. But I'm informing you on the fundamentals, so you will have reliable testing tools. The Web page link I've provided, has a whole set of information and links to other pages on "the fundamentals". With good drives and diskettes (as I've described), you can test your VF II controllers under the conditions they were designed for. If they work under those conditions, you can try other configurations. OK? Good luck, keep me posted. - Herb Johnson You made a lot of good points! Thanks! I'm working on being sure I make use of them! This effort gets more and more "interesting" as I try more and more things. I took your advice about bulk erasing a diskette with a strong magnet. I tried to run an analysis on it (with ANADISK) afterward, and ANADISK said it would not deal with it because it was blank! So the erase worked. I then ran through the same sorts of tests with it as before. Same results. BUT, using ANADISK, I was able to look at the diskettes that I formatted with Monahan's diagnostic. ANADISK only complained about the sectors in the "boot area". Nothing else. Of course the VFII format only does, what, 76 or 77 tracks and ANADISK wants to look at 80, so there were lots of complaints between track 76 or 77 and 80 (as I expected). I thought that maybe there was something odd about the ver. "P" card, so I tried a lot of these tests with different floppy drives and different media with my other (ver. "G") card. Both performed exactly the same. I'm beginning to think that there is something "off" about some parts of the Monahan diagnostic. I formatted a diskette with it (DSDD 512b sectors), and then went to my ANADISK (running on a DOS PC). As I said, ANADISK only had a problem with track 0 side 0. So I picked out a sector outside that part of the diskette, and wrote the upper/lower case alphabet and some numbers and symbols into it. I then took the diskette back to the VFII set-up, and used the function in the diagnostic to load that sector into memory. Sure enough, it loaded the correct content -- no problem, no error! Then I got really curious and hooked up a Mitsumi 3.5" drive with a straight cable (had to refer to it as an 8" drive on B:). It performed exactly as the 5.25" drives I had tried. Got the same results with ANADISK as well. So it appears that at least one kind of 3.5" drive will work (also had to ground "ready"). BUT, because everything I have tried seems to work the same way with respect to the Monahan diagnostic (with all kinds of different drives, media, and both of my VFII cards), I am suspicious of it. I think that next I will try to get Bruce Jones' diskette format software to work, and see if I can format a diskette that way. See what happens with it. Also, I tried to get a little advice from Monahan via e-mail. He wasn't any help.. To respond to some of your comments: - the drives that are dying on me are having more mechanical problems and what seems like electronics failures. I haven't had many problems with drive heads. - I never thought much about HD vs. DD, so I tried some regular DD diskettes. No change. Thanks! - Roger Nov 5 2018 Tracks near the center of the diskette (upper track numbers) are tough. The velocity of the media at the head is slower, so the bit density is higher and the flux density is lower. If you format a DD disk at HD density, it will not fail until about the middle or innermost tracks. And it's clever, to look at non-formatted tracks like 77 thru 80. Strong magnets are DC magnetic fields. There's the risk of magentizing the diskette! An AC magnetic field, neutralizes the disk's magnetic orientation. If you use a permanent magnet, move the diskette across the magnet and pull it far away. I"ve not tried it myself - I must have have a dozen bulk erasers! ;) http://s100computers.com/Software%20Folder/VF/VD%20Diagnostic.htm is John's slightly more recent version of his diagnostic. His is version 1.02 - mine is version 1.01. Roger, you could actually do me a favor - tell me what the difference is, I'll update my version. Oddly enough - John's 1.02 is a *PDF* file. His source file (like mine) is V1.01! YOu'll have to compare the PDF content to "my" .Z80 source! HOpefully there's not too many differences. I can send you the text file extracted from the PDF if necessary. My brief look at his online Web page on his diagnostic, says he didnt test in in all ways. he says "In particular make sure you set the TRUE/FALSE for the 1791 or 1995 chip you are using. Also set the base port for your board. I use 50H to avoid conflicts with a Lomas Video board I have. . SD Systems uses 60H." On ver P versus G. John talks about it: it's about differences in the data seperator. He says he found no operational differences. Of course make sure your phase-1 clock signal on the bus is good. Or you can try inverting phase 2 instead, see if that makes a difference. He also notes the difference between using a 1791 and a 1795, and the diagnostic apparently must be assembled for one or the other to deal with them. Myself, I stick to 8-inch drives and 360K 5.25-inch drives, occasionally 1.2M 5.25 inch drives. I have a stash of older 3.5" drives that can be set as A or B drives, and have means of jumpering the rotating speed to 360 RPM like the 8-inch drives. But i simply use an 80486 computer to read 5 inch and write 3.5 inch and vice versa. - Herb Nov 6 2018 Well, Herb .... I'm embarrassed to tell you that I screwed up. As you told me, the Monahan diagnostic has a TRUE/FALSE flag for the FDC controller chips (1791/1795). His original file has it set for the 1791. I changed that, but then somehow (when I was working on fixing the code so that it would assemble on a "regular" assembler) I managed to get that original FDC setting back into my build, and I neglected to check (because I had fixed it, right?). So the errors I was getting are the result of trying to run 1791 code on my 1795 VFIIs. In looking over the code, as you requested (to compare the two latest versions), I found the error! When I fixed it, things started working OK. I'll attach a copy of my Z80 version of the code [myvf.z80] -- cleaned up, lots (but not all?) typos corrected, and set up for the 1795. I also changed the port addresses back to the "standard" values for the VFII (@ 60H). This file ought to assemble OK on M80-ish assemblers? He does use long labels, and I'm not sure if M80 (or other assemblers of that type) will handle them, but it assembles fine on mine (AZ80). I did find something odd in the original ver. 1.01 code in the "Look-up Table For Disk Parameters" for the 8" DD format (512b sectors). This is a snip of his original code: DB 4EH ;GAP Format fill character DB 0E5H ;Data area fill character DW 0H ;Size in bytes of 1 formatted track DB 28C9H ;No special post formatting modifications of disk req DW SKEW_512 ;Location of this disks sector skew table while most of the other tables have something like: DB 4EH ;GAP Format fill character DB 0E5H ;Data area fill character DW 28ECH ;Size in bytes of 1 formatted track DB 0H ;No special post formatting modifications of disk req DW SKEW_256 ;Location of this disks sector skew table I *think* that the two lines ("Size in bytes of 1 formatted track" and "No special post formatting ....") are reversed in the 8" DD format table, but it's just a guess. >> His is version 1.02 - mine is version 1.01. Roger, you could actually do me a favor - tell me what the difference is I went through the PDF file line-by-line, comparing it to the previous version, and as best I can tell there are only two minor changes. He added to that long list of version comments at the very beginning of the file: ; V0.88 IY working throughout. Seems solid for 1791 & 1795 chips. ; V1.01 Set 1 track for 1K sector 8" CPM system tracks instead of 2 by sticking in another line: ; V0.88 IY working throughout. Seems solid for 1791 & 1795 chips. ; V1.01 Set only 1 system track for CPM 1K sector 8" disks (instead of instead of 2) ; V1.02 Strip parity bit from direct keyboard input (if any). And, then he modified the CI routine (character input) by adding an "AND 7FH" as you can see below: CI: IN A,(0) ;console input AND A,02H JR Z,CI IN A,(1) ;return with character in A AND 7FH ;Strip parity (IF ANY). <<<<======================here! RET Those are the only changes I could find, and I don't really think that they are very significant! BUT, it was really difficult for me to sift through all the output messages at the end of the program, and the data in the disk format descriptor blocks. Got bleary eyed! *grin* Hope I didn't miss anything! I think that if there were significant changes there, he probably would have mentioned it in the versioning comments at the beginning of the program! Anyway, I'm happy! I can run the diagnostics on both 5.25" HD and 3.5" drives, and they work! I'm really glad about the 3.5" drive because (as I mentioned) I'd like to see if I can get one of those Gotek floppy emulators to work on this system. It would be a good solution for my problems with dying floppy drives and dodgy media, if I can do it. Thanks for your help! - Roger Nov 7 2018 Hi Herb, Yep. Things are looking pretty good right now with respect to the VFII and either 5.25" HD drives, or 3.5". >> Chances are, I'll want to put your version on my Web site - let me know that's OK. Sure!! Go ahead. I did some more work on [myvf.z80] last night, and added the ver. 1.02 change (although I don't really think it's very significant to the overall operation of the diagnostic). I'll attach the newest file. Yes, I think that the changes I made will make it easier to assemble with more of a variety of assemblers. I think that I got about 400(!) errors when I tried to assemble Monahan's "Z80" file straight from the download. >> Keep me posted on those Gotek emulators if you get one. I've already got two! The whole Gotek picture seems quite convoluted. The firmware that comes with the device is apparently not very good, so I think it is best to flash it with new code. In order to do that, you have to use a flash programmer from ST (yes, *that* ST -- maker of chips). Seems the flash code only runs on some sort of Windows. I think that there are 2 or 3 different pieces of code that can be flashed to the Gotek. The free one(s) seems to be set up for PC style formats only, so might not be so good for what I want. There is another (licensed) one from HxC. They are in France. Costs 10 euros (whatever that is in USD). Worst part is that they only do credit cards. Gives me the creeps to send credit card info. to France. Anyway, they claim that their software can do just about any floppy format. And they have a Linux version, so that's good. In addition, I think that there has to be another piece of code that runs on a host system that formats the USB flash stick (the one that holds images of all your floppies) and manages it. I'm trying to learn about all of this, but it is hard to get a complete picture. It will be a learning experience, I'm sure! Before I attempt anything with the Gotek, I will have to write a new CBIOS for my system that can read/write one of the formats that Monahan uses in his diagnostic, or write my own formatter (which I really don't want to do). If I can get that working (say on a 3.5" drive), then I'll see about the Gotek. Roger Sorry to keep bugging you, Herb, but I found something yesterday in the Monahan VFII diagnostic code that is far more serious than the other typos and errors that I've pointed out to you. In the "WRITE_SECTOR" routine, in the retry section (toward the end of the routine), there is a call to "AGAIN_RD"(!). I think he meant to call "AGAIN_WR"? It is the line just before the label "BAD_WR". If you look at the "READ_SECTOR" routine (it's very similar), you will see that at the analogous point in that code, there is a call to "AGAIN_RD". This is just a guess on my part. Only Monahan would know for sure. I looked at the PDF of the diagnostic that is on his site, and that call (to "AGAIN_RD") is present in it as well. What do you think? - Roger NOv 8 2018 Thanks for calling this out, Roger. I'll have to read the code with some care. Obviously you are more familiar with it than I, probably more than John at this point. But follow the logic, see if he does mean to read again before write, or not. YOu can compare his PDF of the 1.2 with his ASM of 1.1 from my site, see if was some kind of edit issue. Also: archive.org's internet Wayback machine, keeps back-pages of some popular Web sites. There may be an earlier version of his diagnostic code there. Entirely up to you to work hard to find older copies. But John himself says he didnt' test everything in his code. Again, I'll see about looking at it myself. - HErb