PDA

View Full Version : Issues with 5 1/4" drives and the Versafloppy II



JNZ
February 18th, 2016, 12:53 PM
I've been messing with a VersaFloppy II board and trying to get it to work with my 5 1/4" drives. I've been having some issues, however. I think it might be best if I first explain some assumptions I have about drives and media, and if I say something wrong please correct me:




There are a few commonly available 5 1/4" drives. I have three: a TEAC FD-55FR-511-U 720KB 300RPM drive, a Toshiba ND-0801GR 1.2MB 360RPM drive, and a Fujitsu M2553K 03B 1.22 MB drive that may not be working.

The VersaFloppy II is designed to work with 8" or 5 1/4" drives. With the right software, it should be able to control 360 KB, 720 KB and 1.2 MB drives.

John Monahan's VersaFloppy II diagnostic program is a recommended way to test out and control your drives. I've gotten this running, but I'm not sure it works with 720 KB or 1.2 MB drives.

Drives rotate the disks at either 360 RPM or 300 RPM. 300 RPM results in a lower density. Some drives have a jumper to switch speeds (my Toshiba) and some have a pin that they listen to to vary the speed. The VersaFloppy II's IOByte has a bit that identifies whether it's high density or low density, which is then sent to the floppy disk. Any low density format should be on a drive that rotates at 300 RPM.

In addition to the drives, here are my assumptions about disk media:


There are a number of hard-to-identify disk formats: Single or "High" density, Double or "Quad" Density, and each of these can be Double or Single Sided.

Any disk media starts out as a blank slate of magnetic material, with either DD or SD media, which are physically different. When you format a disk you create the tracks and sectors--they're not created that way at the factory.

A DSDD disk can work as 720 KB, 1.2 MB, or 360 KB.

A STEP command sent to a 360 KB drive will rotate the stepper motor twice as much as on a 720 KB or 1.2 MB drive. This is because the RW head is fatter, and needs to go twice the distance to avoid magnetic interference. So the VersaFloppy II controller needs to double-step a 700 KB or 1.22 MB drive if it thinks it's talking to a 360 KB drive.

Double stepping a drive occurs by the user's software passing the correct parameters to the VersaFloppy II and its WD 179x controller chip.

Before I get deeper into this, please let me know if I have some fundamental misunderstandings.

1944GPW
February 18th, 2016, 01:21 PM
Can't offer much help but 30+ years back I used to run a Teac FD-50A 5-1/4" drive (single-sided) with my Versafloppy II, and from memory had no problem, so I'm only guessing your FD-55 would be ok.

Chuck(G)
February 18th, 2016, 01:45 PM
Disks that rotate at 360 RPM have a lower density (flux changes per linear inch) for a given clock than 300 RPM. Consider, for example, a 300 RPM 1.44MB HD drive vs. a 360 RPM 1.2MB drive (same number of tracks).

3.5" 360 RPM HD drives also exist and, like 5.25" 360 RPM HD correspond to 8" formats. As a matter of fact, the NEC PC98 series uses the same format on all disks, regardless of physical size.

MicrocomputerSolutions
February 18th, 2016, 02:17 PM
#5. For 5.25" mini-floppy disk drives drives there is single, double, high, and Quad density. There are single and double sided. And there are 34, 40, or 80 tracks on a side, spinning at 300 rpm for all capacities except for 1.2mb (which spins at 360, the same speed that all 8" floppies spin).

#6 For 5.25: mini-floppy disk drives there are different recording formulas for the magnetic oxide that is spread onto the disks: is single density, double, high, and quad density. All disks are coated on both sides, but only double-sided disks are certified to be used in double-sided drives.

#7 All diskettes whether designated as single or double sided were manufactured for use at declared density ratings (single for single, double for double, high at high, and quad at quad). They may sometimes work at other densities. Single density disks work for single and double density, and sometimes work as high density, but rarely work at quad density. High density disks are not made to work at quad density, but usually work at single and double density. Quad density (1.2mb) may or may not work at single, double or high density.

#8 A step command on a 40 track drive will physically move the read/write head/s twice as far as a step command given to a 80 track drive. Don't assume that the distance/motion is in the stepper motor, sometimes it's in/due the worm (pitch) screw or pulley (diameter) attached to the stepper motor.

The magnetic track of the head on a 40 track drive is wider than that of a high density or quad density drive. Floppy drives lay down/record a dead space at the outside edges of the data tracks to help prevent noise on the "blank" areas of the disk from interfering with valid data. Because the recorded data track is narrower on a 80 track drive, 40 track drives (if they are not aligned perfectly), may not be able to read and write disks that were formatted on and written by a 80 track drive.

The distance of a drive's step is fixed by drive mechanicals, and logic. The computer's primitive's (SD Systems has a Monitor Bios with diagnostic tables for the common 5.25 and 8" drives being made at the time, the PROM on my Versafloppy II does not support any 80 track 5.25" drives) tables OR OS remembers the operational information on the drive programming on the disk controller board tell the disk controller board. The OS or Primitives contain the information for disk recording formats. Normally, the drive (regardless of whether it is a 40 track or 80 track drive operating as a 40 or 80 track drive with 40 track disk in the 40 track drive, and 80 track disk in the 80 track drive) is going to have a valid track under the heads each time the drive is commanded to step. If the OS is programmed for use with 40 track and 80 track disks, and knows that a drive is physically 80 tracks and a 40 track disk in mounted, then it should know from looking at the OS, that it needs to send two step commands to get to the next track. The disk controller board (the exception to this would be a disk controller board that has a PROM onboard) and disk drive do not store information on how to get to the next track, they only perform the command sent by the CPU.

9. Double stepping to get to the next valid track on a 40 track diskette when mounted in a 80 track high density drive occurs when the Processor board sends two step commands to the disk controller board.

JNZ
February 18th, 2016, 02:24 PM
Disks that rotate at 360 RPM have a lower density (flux changes per linear inch) for a given clock than 300 RPM. Consider, for example, a 300 RPM 1.44MB HD drive vs. a 360 RPM 1.2MB drive (same number of tracks).

3.5" 360 RPM HD drives also exist and, like 5.25" 360 RPM HD correspond to 8" formats. As a matter of fact, the NEC PC98 series uses the same format on all disks, regardless of physical size.

Ah yes, thanks for clearing that up. That makes more sense

Here are the types of errors I'm seeing with John's VF2 diagnostic program whenever I try any combination of drives or disks that I have available:



VERSAFLOPPY II DIAGNOSTICS ---- MAIN MENU ---- (Detail Display OFF)
Current drive:- 5", DDSS. 128 byte, SD-Systems Format
Drive B: (IOBYTE)=01100010 Size=5", Single Sided, Double Density disk.
Current Disk [IX] Table: Sec/Track=1DH, Tracks/Side=23H, 128 Bytes/Sec.

SEC ID Error. Bits: DNR,0,0,RNF,CRC,DATA,DRQ,Busy (00010000)


and



SEEK Error. Bits: DNR,WP,Head,Seek,CRC,TRK0,INDEX,Busy (00010000)
TRACK 00H.
SEC ID Error. Bits: DNR,0,0,RNF,CRC,DATA,DRQ,Busy (00010000)


It's always SEEK or SEC ID errors.

new_castle_j suggested that I check the RW head and see if it's not moving more than halway into the disk. I think that might be the case, which indicates to me that the drive isn't properly double-stepping.

The WD179x datasheet indicates that the step signal will be sent for 2 microseconds if the double density bit is set, and 4 microseconds if it's unset. It would seem that John's code is putting this out to the card correctly, on port 63H, which it seems right.

There are also timing options for waiting for commands to complete, and I increased these to their 30 ms maximums as per the comments in the code and the WD179x documentation.

What could be causing the SEC and SEEK errors? They happen both before and after formatting a disk, and it happens no matter what type of disk and format I select.

MicrocomputerSolutions
February 18th, 2016, 02:43 PM
The VersaFloppy II was designed before 80 track 5.25" drives existed, so they aren't supported in the SD Monitor (at least they are not supported in my PROM or the Manual that came in my VersaFloppy II). Not knowing what you have in the way of firmware support for floppy drives, I'd suggest starting out with a 40-track drive if you are going to try to use 5.25" drives.

I see not reason why you can't write the SD Monitor (or your PROM) to support 80 High Density Drives. My Versafloppy II works on the first 40 tracks of a 80 track high density drive, so all that's needed to make it work 80 tracks would be a PROM change (and OS Modifications change if wanting to use 80 tracks disks under CPM 2.2 and/or SDOS).

The trick has always been to find a PLL circuit adjustment that works on both 5.25" and 8" drives when the boards are both cold and warm. I had a friend who built an S-100 System the same time that I did using the SBC-200, Expandoram 64, and Versafloppy II. He had an earlier version of the VersaFloppy II that utilized a pot that laid flat on the upper left hand corner (as you are looking at the board) and adjusted from the front of the board. I had the next version of the board, which used a 20-turn pot that was mounted pointing up at the top edge of the board that was adjusted using a screwdriver from the top edge of the board. His earlier board was more sensitive to heat than my later version, and they both had a tendency to drift after heating up. I had my VersaFloppy II adjusted to work when warmed up. I would turn my system on, load a disk, and let it run for 5-10 minutes before I used it. The System would try to read the disk and fail until it warmed up, at which point it would start reading the disk and boot up.

For optimal function, 5.25" and 8" disks like having the pot in the PLL circuit tweeked slightly differently. I had to work to find a compromise that allows both size drive to work well.

MicrocomputerSolutions
February 18th, 2016, 02:50 PM
Ah yes, thanks for clearing that up. That makes more sense

Here are the types of errors I'm seeing with John's VF2 diagnostic program whenever I try any combination of drives or disks that I have available:



VERSAFLOPPY II DIAGNOSTICS ---- MAIN MENU ---- (Detail Display OFF)
Current drive:- 5", DDSS. 128 byte, SD-Systems Format
Drive B: (IOBYTE)=01100010 Size=5", Single Sided, Double Density disk.
Current Disk [IX] Table: Sec/Track=1DH, Tracks/Side=23H, 128 Bytes/Sec.

SEC ID Error. Bits: DNR,0,0,RNF,CRC,DATA,DRQ,Busy (00010000)


and



SEEK Error. Bits: DNR,WP,Head,Seek,CRC,TRK0,INDEX,Busy (00010000)
TRACK 00H.
SEC ID Error. Bits: DNR,0,0,RNF,CRC,DATA,DRQ,Busy (00010000)


It's always SEEK or SEC ID errors.

new_castle_j suggested that I check the RW head and see if it's not moving more than halway into the disk. I think that might be the case, which indicates to me that the drive isn't properly double-stepping.

The WD179x datasheet indicates that the step signal will be sent for 2 microseconds if the double density bit is set, and 4 microseconds if it's unset. It would seem that John's code is putting this out to the card correctly, on port 63H, which it seems right.

There are also timing options for waiting for commands to complete, and I increased these to their 30 ms maximums as per the comments in the code and the WD179x documentation.

What could be causing the SEC and SEEK errors? They happen both before and after formatting a disk, and it happens no matter what type of disk and format I select.


You must use the correct disk media for the drive that you are trying to use. Do you know for a fact that the 720K 80 track drive is functioning correctly? Have you run it on a PC to verify operation and that the media works with the drive?

If the Teac drive is working, and you have the correct media, you can format the disk as 40 track, and you don't care whether the drive is double stepping to hit the normal 40 tracks or is single stepping any only using the outside 40 tracks of a 80 track drive. The only thing that you should care about is whether the drive is stepping on command to the same places every time you issue a step command, and whether the drive can read and write on the track that it lands on. If the drive can do that, then you can fix the OS and Primitives to support all of the tracks later.

If the PLL cicuit is not working correctly, the drive will not be able to read the disk and I would expect to see the type of errors that you are getting. Have you sucessfully run this VersaFloppy II with a 8" drive? You need to get some components that you can confirm are working to be able to figure out what is not. Without a known good drive, and with media that is known to be work with the drive, you have too many equations with too many unknowns to solve.

You gotta crawl before you walk, and walk before you run....

JNZ
February 18th, 2016, 03:14 PM
This is very good information, MicrocomputerSolutions, and a lot to digest. I can't experiment much at the moment, but I'm going to reread this and ponder what's best to do next. I can't test my Versafloppy II board with my 8" drives because I don't have the proper connector, which is a 50pin two-row female IDC connector to a flat 50-pin female connector for plugging directly onto a PCB. I
need a cable and/or an adapter that changes the type of connector on the VF2.

I'm not completely sure that the 5 1/4" drives work either; I was relying on the general reliability of the drives and the fact that they worked when I last used them (many years ago). I could install one into an old PC to test, and it should be relatively easy. It might be necessary.

One thing I'd like to be sure I'm clear on: if I'm using a drive that can support 80+ tracks (my 720KB TEAC drive), I shouldn't really care if it's using the first 40 tracks instead of using track 0, skipping track 1, using track 2, skipping 3, etc., so that it's only using 0 + even tracks. Thus I shouldn't need to make modifications to the diagnostic program to double step, at least initially. The drive should be capable to read and write the first 40 tracks on a double density disk, and the controller will be perfectly happy thinking it's a 40-track disk and 40-track drive.

This leads me to believe that either: my modifications to the code to increase the write timing screwed something up (an experiment to see if the 15ms vs. 30ms option would help me), and/or none of my 5 1/4" drives actually work. Or, of course, something's wrong with my VF2.

Like you said, I have too many variables and should eliminate them before I go forward. I'll have to do this later tonight...because, in unrelated news, I shuffled over to my computer in my moccasins and went to set my laptop down, which made me electrically shock another component plugged into the same outlet. The S-100 computer immediately froze but remained on, but, very bizarrely, when I turned it off and on the 3A fuse blew! I don't have any on hand. I hope the shock didn't somehow travel through the mains supply to the S100 and short some component out. It sounds crazy that the fuse would blow after the power cycle, but not during the static shock. Maybe it was somehow drawing enough parasitic current through another component, like the serial connection, to keep the frontpanel lights illuminated? Very weird.

new_castle_j
February 18th, 2016, 03:19 PM
I think that John's program only contains 5.25 disk formats for 40 track drives. All of your drives are 80 track, or 96 TPI. The read/write head on 96 TPI drives lays down a track width that is half that of a 40 track drive. A double-stepping 96 TPI drive should be able to read a disk that was written on a 48 TPI drive, but don't expect a 48 TPI drive to be able to read a disk that was written on a double-stepping 96 TPI drive. Another trouble is if you have a disk that was written on a 48 TPI drive and try to erase it with a 96 TPI drive, the erase head will not be able to erase the full trackwidth and you're left with residual bits. So, if you have a double-stepping 96 TPI drive, you should first degauss or bulk-erase the media.

Here's a thread that describes converting the TEAC FD-55 from 80 track to 40 track by cutting a resistor, causing the hardware to double step the head.
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/modding-a-teac-fd-55-for-double-step-%2880-to-40-track-conversion%29/

JNZ
February 18th, 2016, 03:29 PM
I think that John's program only contains 5.25 disk formats for 40 track drives. All of your drives are 80 track, or 96 TPI. The read/write head on 96 TPI drives lays down a track width that is half that of a 40 track drive. A double-stepping 96 TPI drive should be able to read a disk that was written on a 48 TPI drive, but don't expect a 48 TPI drive to be able to read a disk that was written on a double-stepping 96 TPI drive. Another trouble is if you have a disk that was written on a 48 TPI drive and try to erase it with a 96 TPI drive, the erase head will not be able to erase the full trackwidth and you're left with residual bits. So, if you have a double-stepping 96 TPI drive, you should first degauss or bulk-erase the media.

Here's a thread that describes converting the TEAC FD-55 from 80 track to 40 track by cutting a resistor, causing the hardware to double step the head.
http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/modding-a-teac-fd-55-for-double-step-%2880-to-40-track-conversion%29/

Hmm, but is there a reason I should be unhappy with an 80-track drive using only 40 tracks, and just using the first half of the linearly available disk media? I likely don't have any existing disks written in a 40-track drive, nor a 40-track drive to accidentally try and put 80-track media into. I also have 25 new (2011) DSDD disks (I finally found out what they are), so I should be able to use those, I think.

Why do people do the double-step modification, especially since the reduced flux density of the outer tracks means that those portions of the disk are generally more reliable? Is the only benefit that a double-stepped 40-track disk is still compatible with a real 40-track drive?

MicrocomputerSolutions
February 18th, 2016, 03:33 PM
I have boxes of ribbon cables, and drawers full of connectors but I always seem to need to go to the store when I'm working on a project for a customer. I've always spent a lot of time in surplus store looking for ribbon cables and connectors because surplus cable with the connectors already on them is the least expensive way to get both cable and connectors (if you can remove the connectors from the cable without breaking them).

A few weeks ago, I promised cables to someone with the hardware they were buying and I needed some connectors. I ended up buying $50 worth of cables and connectors when I only needed to get $16 worth. But I could not turn down the opportunity to get new 3M 50 connector females for $2 each, even though they didn't have the chassis mounting ears that I wanted. And I bought some new 6' long 50 conductor ribbon cables with a 50-edge, and male 50-IDC on the other end for $2 a piece (exactly what you need).

MicrocomputerSolutions
February 18th, 2016, 03:56 PM
If you are planning on using 40 track disks, and trying to interchange with other people, you would be better off having a 40 track drive. For the reasons that I explained previously, it's easier to run a 40-track drive, with 40 track media, when interchanging 40 track disks with other people because the alignment does not need to be as precise.

I suggested running the outer 40 tracks of a 80 track high density drive as a way to test and verify that the drive is working with the controller, not as a permanent thing.

Double stepping is a compatibility thing for people who have 80 track drives and need to read and read 40 track disks.

If you want the maximum interchangeability for CPM disks, you want 8" drives, and you are going to want to make your interchange disks IBM 3740 single-sided, single density. It's the only universal interchange format between different computers.

There is no reason to reinvent the wheel unless you want/have time to waste. Kaypro, Morrow, and Osborne Systems came with format changing systems on 5.25" included on their Systems. Compupro and Morrow had format changing software for 5.25" and 8" drives for their S-100 Systems (MSDOS and Windows included). New Generation Systems sold Diskmaker Software both standalone and in a package with a Suntronics S-100 floppy controller (controls both 5.35" and 8" drives at the same time).

The Suntronics floppy controller can run in a System as a 2nd floppy controller, and you load and run the Diskmaker Program only when you need to read or write disks for other Systems. I keep one as a backup, but the format changing program that is included with Compupro Versions of Digital Research OSs works fine for all my needs.

I have one 80 track high density double-sided 5.25 720K Mitsubishi 4853 drive on my Compupro System, and I have no problem reading writing to disks formatted on my Compupro or on another computer that uses 40 track drives. But, as I wrote before, both types of drives have to be in good/perfect alignment for this to work without problems all the time.

Chuck(G)
February 18th, 2016, 08:03 PM
[QUOTE=JNZ;402752]Hmm, but is there a reason I should be unhappy with an 80-track drive using only 40 tracks, and just using the first half of the linearly available disk media? I likely don't have any existing disks written in a 40-track drive, nor a 40-track drive to accidentally try and put 80-track media into. I also have 25 new (2011) DSDD disks (I finally found out what they are), so I should be able to use those, I think.[/url]

Should work okay--one of the formats for the Zenith Z-37 box did exactly that. Not double-stepped, just used the first half of the 96 tpi drive. I never did understand the logic, but I've got samples in my files.

JNZ
February 22nd, 2016, 10:13 AM
So I tracked down another 1.22 MB 5 1/4" drive and tried that, as it was more readily available than putting one of my drives in a PC machine and getting it going. At this point all four drives result in the same error, so I'm comfortable in pursuing the idea that it's the VFII board.

@MicrocomputerSolutions, can you tell me more about the operation of the PLL circuit and what it's used for? I located it on the schematic but a high level overview would be helpful.

The VFII manual lists some tests I can do to adjust it, but before I tinker I'd like to understand it and do measurements. The adjustment procedure they list is to just make the disk seek and then change the pot until a type of hesitation is minimized.

I also verified that I have a Phase 1 and Phase 2 clock on my S-100 bus. The second clock signal (Phase 1 I think, the one that isn't on IEE-696 compliant boards) is a little lower in voltage than the Phase 2 and has more ringing, but it's rock steady at 4.000 MHz.

I'll also start with a stock version of John Monahan's VFII diagnostic and diff it with my current version, to ensure that I only changed the console IO routines.

Edit: I located a test point on my VF2 board (test point 3) that lets me see the output of U13, the voltage controlled oscillator that is connected to the trim pot in the PLL circuit:

https://i.imgur.com/fSvQC6l.png

Now I have a baseline if I make modifications.

MicrocomputerSolutions
February 22nd, 2016, 11:57 AM
I've never run a 1.2mb 5.25" Drive on the VFII. Never had a reason to even try it. And I haven't needed to adjust the PLL circuit on my VFII in DECADES. But here's how I remember doing it.

You must start with a correctly running set of floppy drives before trying to adjust the PLL circuit. You can't pull a drive of unknown condition out of a pile, slap it on the VFII, and expect it to work. Get a correctly aligned drive 5.25" drive (you also need to have a correctly aligned 8" drive check test function after doing the 5.25" drive). Understand that the best PLL pot adjustment for each drive size is going to be different. You need to determine the best setting for each drive size, and find a compromise setting that will allow all the drive sizes you are running to work correctly.

There are no shortcuts to getting the VFII working. To adjust the PLL, power the computer on, and replace the cover on the computer and wait 15-20 minutes for the temperature to stablize. Then, adjust the pot in on the PLL circuit, and try rotating the pot until the PLL circuit is working, and the drive appears to be working. Make a note of that position. Then pick a single direction, and rotate the PLL pot 1/16 of a rotation (pick a direction at a time clockwise until the drive stops working/reading). Make a note of that position. Then, rotate the pot back to the position that the VFII was working and verify that it is working. Now rotate the pot 1/16 of a rotation at a time in the opposite direction until the VFII stops working, and make a note of that position. Then set the pot back to the center of travel between the two positions on the pot that the VFII was working correctly.

After that, switch to an 8" drive, and verify that the 8" drive is working properly. If it is not, try adjust the PLL pot to find the best position for it, the same way that you did for the 5.25" drive, and see if both drives will work if you set the PLL pot half way between the best adjustment for both size drives.

MarsMan2020
February 24th, 2016, 07:35 PM
I would really dig into John's code and maybe post on the S100Computers forum (https://groups.google.com/forum/#!forum/s100computers) before altering the PLL pot settings on your board.

A few thoughts:
-There are two EQUs in John's source code (http://www.s100computers.com/Software%20Folder/VF/VF.Z80.pdf) that need to be set TRUE/FALSE based on if your board has a WD1791 or a WD1795 controller chip. Do you have that set properly? The read/write commands are different for the two chips and apparently there were boards sold with either chip over the years. Having the wrong setting could surely cause immediate errors.

-Do you know that you have known good media in a known good drive. I've gone through some stacks of old floppy drives lately and 1/3 of a given type didn't work and I just tossed.... I also have old floppies that were improperly stored previously where the oxide is disintegrating off the floppy. It would be way easier to have a known-good system to get going (I did not on my Vector MZ, which made getting it running a stab in the dark).

-What commands (if any) have you run in John's program to produce the above errors? You should be able to trace through the source code to figure out why you're seeing that error. Is there a chance that the sector geometry it is expecting is different from what is actually on your disk, hence the sector errors (say it's looking for more sector than there actually are on the disc)? In the "header" into, the sector/track numbers shown do not match up with an IBM-formatted floppy...

I went through a similar thing with my Vector MZ (adjusting trim pots on the Micropolis controller board, using a logic analyzer to set the pulse durations) - but the problem I was having of unreliable operation turned out to be bad 4116-4 RAM chips. Every time I have to troubleshoot something like this is goes back to understanding exactly what the software is asking of the hardware and what the state of the hardware is....I would get really familiar with what that program is doing before going anywhere else.

JNZ
February 25th, 2016, 06:21 PM
I'm waiting for a cable that new_castle_j is sending me so I can use my 8" drives on my VFII, so I'm holding off on replying to some of these helpful suggestions. I can answer these, though:

>A few thoughts:
>-There are two EQUs in John's source code (http://www.s100computers.com/Softwar.../VF/VF.Z80.pdf) that need to be set TRUE/FALSE based on if your board has a WD1791 or a WD1795 controller chip. Do you have that set properly? The read/write commands are different for the two chips and apparently there were boards sold with either chip over the years. Having the wrong setting could surely cause immediate errors.

I forgot to mention this, but I did verify that I have the 1795 and I set the EQUs for the chip. (I tried it the other way just for fun, but to no effect)

>-Do you know that you have known good media in a known good drive. I've gone through some stacks of old floppy drives lately and 1/3 of a given type didn't work and I just tossed.... I also have old floppies that were improperly stored previously where the oxide is disintegrating off the floppy. It would be way easier to have a known-good system to get going (I did not on my Vector MZ, which made getting it running a stab in the dark).

I previously didn't know this, but I booted up an old PC and verified that my new TEAC 1.22 MB drive is operational, and I formatted it in DOS (DSDD 9 sectors/trk., 90 tracks, IIRC) and wrote/read data from the disk.

>-What commands (if any) have you run in John's program to produce the above errors? You should be able to trace through the source code to figure out why you're seeing that error. Is there a chance that the sector geometry it is expecting is different from what is actually on your disk, hence the sector errors (say it's looking for more sector than there actually are on the disc)? In the "header" into, the sector/track numbers shown do not match up with an IBM-formatted floppy...

I haven't gone all the way into this yet, but I see the seek errors all the time, even when the main menu prints or any command that requires seeking executes. I think I see it so often because it's used in the HOME command, as well as seeking, reading, and verifying that it's in the proper position to write. It's all one function call at the heart of it, and I used the WD datasheet to verify that it's using the correct commands with the correct timing (I tried the more forgiving +30ms options too).

>I went through a similar thing with my Vector MZ (adjusting trim pots on the Micropolis controller board, using a logic analyzer to set the pulse durations) - but the problem I was having of unreliable operation turned out to be bad 4116-4 RAM chips. Every time I have to troubleshoot something like this is goes back to understanding exactly what the software is asking of the hardware and what the state of the hardware is....I would get really familiar with what that program is doing before going anywhere else.

Hmm, what RAM are you referring to? The system RAM, or does the Vector MZ have on-board RAM for buffering? When I first got my system running I did a memory test a few times, and my system RAM passed the tests.

There are some troubleshooting steps in the VFII manual that I haven't done yet. I have to go down that list and verify proper operation item-by-item, starting with simple things like proper voltages and working up to logic.

MarsMan2020
February 27th, 2016, 09:58 PM
Hmm, what RAM are you referring to? The system RAM, or does the Vector MZ have on-board RAM for buffering? When I first got my system running I did a memory test a few times, and my system RAM passed the tests.

System RAM. If you ran tests you are probably good.

JNZ
March 24th, 2016, 08:07 PM
I have an update on my troubleshooting process with my VFII. New_castle_j of this forum very helpfully let me borrow his VFII, which was in a known-good condition with a similar S-100 system. Using his board I was able to verify the operation of both my 5 1/4" 1.44 MB TEAC drives and two of my 8" Siemens drives (including the one that came from eBay, which checked out just fine). I was able to read and write data to the drives using John Monahan's VFII diagnostic program. I did see some interesting but consistent behavior where it seemed that not all of the information in a sector was written, but it's something I have to return to.

Using the borrowed board I looked for differences. One of the main ones is that my board wasn't modified to generate its own replacement for the Phi 1 signal. This modification is necessary in systems that use IEE-696 compliant Z80 boards, which don't provide the Phi 1 inverted clock line. Since I'm using a non-IEE-696 Jade "Big Z" Z80 board, I figured this was fine.

Upon probing my Phi 1 bus signal (pin 25), however, I see this:

https://i.imgur.com/Ngtz1VW.png

CH1 is the system clock (pin 24) and CH2 is Phi 1. You can see what looks almost like an echo of the main clock, but it's barely above the noise, has a DC offset, and certainly isn't 1*Pi out of phase.

On the borrowed, modified board the input into the octal buffer coming off Phi 1 was much the same: whatever modifications were made, they added the signal back in later down the line (and cut the trace to the S-100 Phi 1). When I probed down this line a bit however, by looking at the clock line for a flip-flop (pin 3 of U34), I saw the following:

https://i.imgur.com/c3JZUuW.png

CH1 is again the system clock, and CH2 is a (somewhat messy) square wave that's more-or-less 1/2 out of phase with the system clock. The spaghetti wires all over this board succeed in doing the job of providing the inverted clock that the VFII requires in some way. Jon Monahan's site says it's used for strobing data to and from the WD179X controller, though to me on the schematic it looks like it just comes back to the PRDY bus signal. I don't really know what it does.

TL;DR: Anyway, it's safe to conclude that my Z80 board isn't providing the Phi 1 signal that I'd expect, leading to the observed behavior of being unable to read/write data from the drive (though I can send commands and reliably read/write data to the IO ports on the VFII, as proven by test 7-4 on pg. 19 of the VFII manual).

JNZ
March 26th, 2016, 08:20 PM
Knowing what to focus on, I examined my Jade "Big-Z" Z80 board and found that there was a hard-to-see cut trace on the back of the board that led to Phi 1. I jumped the trace and saw Phi 1 being generated properly:

https://i.imgur.com/aKvXAxF.png

A quick test of my VFII did not succeed, however, failing with the same sector and seek errors as before.

JNZ
April 3rd, 2016, 07:09 PM
I don't know who's following this thread (and in what detail), but by doing the above modifications and by making my VCO for the PLL loop on my VFII match the other board (rather than following the adjustment procedure in the manual) I was able to make my board talk to my drives! It now produces identical input and output when I read/write from a disk! Hoorah! I intend to use the code in the VFII diagnostic as a guideline for making GETSYS and PUTSYS programs, and to then write my own BIOS for CP/M.

JNZ
April 12th, 2016, 12:00 PM
Here's an interesting tidbit that tripped me up for hours and hours. I couldn't for the life of me figure out why my console output code wasn't working. It was behaving as if it wasn't waiting for the transmit buffer to be empty, even though I literally copied and pasted the same code from another program, where it worked fine. The code is:




; siost is the status register, and sioda is data

co:
;console output (arrive with character in c)
in a,(siost)
and a,01h
jr z,co
ld a,c
out (sioda),a

ret



I wrote this code in the VFII diagnostic program and copied it over for a GETSYS program I'm writing. It worked just fine when I compiled it in the diagnostic program.

Well, it turns out that the line
and a,01h assembled into the correct opcode E6byte in the previous program only because I used ZASMB on CP/M (which is a fairly buggy assembler). For this new program I was using z80asm, which interpreted that line as
and a which is opcode A7. The register A anded with A can't be relied on to set the Z flag in this case, and thus the code would never wait for the transmit buffer to be empty.

The correct code is, of course:
and 01h which ands A with 0x01, the mask for checking the transmit status bit.

This isn't the first bug that's tripped me up in ZASMB, and hopefully I won't need to use that compiler anymore.

JNZ
April 12th, 2016, 12:18 PM
During all this debugging I also got tired of constantly standing up and resetting my computer when my code made it lock up. I wrote a dead-simple program for the ATMega328p that waits for "r" on the serial interface and drives two pins in a timed sequence, which stops the CPU, toggles reset, then starts the CPU.

https://i.imgur.com/HCGpUqpl.jpg (https://i.imgur.com/HCGpUqp.jpg)

https://i.imgur.com/y3Dqbwsl.jpg (https://i.imgur.com/y3Dqbwsl.jpg)



r
Stopping CPU (pin 2 low)
Resetting (pin 3 low)
Starting CPU (pin 2 and 3 high)
Done



Clearly it's just hacked together, but any engineering solution that helps me be lazier is a win.

tingo
April 17th, 2016, 07:52 AM
Assembler, not compiler. ;)
Otherwise - you are doing well, nice progress! I'm reading with interest.