Bringing Up a Vector Graphic MZ

Could the varying checksums I am seeing be caused by the last 3 lines of the .hex file?

:1008E00023B6F2E108237EAFC97EB7F2E908E60F2E
:0508F000A8C2E908C9DF
:0508FB004CFFFFFFFFB0
:0209020000FAF9

I looks like it loads 5 bytes from 08F0 to 08F4 and then 5 more bytes from 08FB to 08FF, then 2 bytes from 0902 to 0903.

This appears to me to leave whatever was already in RAM in 08F5-08FA and 0900-0901. So anytime I run a TEST and it writes the random pattern to the RAM, it would change those values and hence the checksum overall of 0100-0903 when I next load the file.

Yes, if I run CHECKSUM many times in a row I get the same values every time.

Checksum the PROM: Q E000 E6BC, you should get B4
Memory test ZCB RAM (used by the monitor): T FC00 FFC0, you should see a steady stream of periods.

Confirmed that the PROM from E000 to E6BC checksums to B4 and a memory test of the ZCB RAM from FC00 to FFC0 gives a stream of periods.

Good observation on the checksums! The "holes" at the end of the hex file could easily cause the checksum variations you are seeing based on the data already present in memory in the holes.

Looks like safer a checksum would be from 0100h to 08F4 (gives 52) or fill memory with zeros first: "Z 0000 DFFF 00" and then load the program. In fact, see if the program happens to run properly after initializing RAM to a known value!

With memory zeroed out (Z 0000 DFFF 00) loading the program gave me a checksum value for 0100-0903 of 94. When I ran the program and hit "Enter" at the first prompt, the system appeared to soft reset (the monitor "banner" came up again). And the checksum for 0100-0903 is now 84, so something in that block of memory was changed in the process.

Edit: I made a second attempt, zeroed, loaded and confirmed the 94 checksum again and the system hung and after reset the checksum is now 28. So something is altering the program which is why I can't re-run it again after a soft reset. Weird.

Wow, this one is confusing! I'll make a version that runs in a totally different section of memory tomorrow and see if that makes a difference. I have a feeling this is going to be one of those, "oh duh!" moments in the end!

I appreciate all of your help for sure! Just to check things out, I re-zeroed the RAM, loaded the program in *without running it* and did a soft RESET and re-ran the CHECKSUM 0100 0903 ~10 times. This came out to 94 every time.

My plan was to break the CHECKSUMing down into 10 blocks of ~100 bytes each and try and figure out what addresses are getting written to and changing the program.

However, when I did a 'G 0100' *after the soft RESETs*, I got the second prompt for a disc! I popped one into the left drive and started the XMODEM transfer, but the drive light never came on and the transfer timed out at 1.3%. I did notice the light on the right drive came on for just a second. So I soft reset *again*, verified the CHECKSUM still came out to 94, and the program worked fine - AGAIN! So I put a disc in the *right* drive, and the transfer is humming along right now.... at like 107 bytes/second (seems awful slow, is that normal?) and 10%.

I don't understand why a soft reset after loading the program would make any difference. That does not make any sense to me at all.

Edit: I've got my serial console at 1200 baud so the fastest it would go would be 150 bytes/s, so ~110 with overhead seems reasonable to me.

Well, I waited the ~45 minutes it took to write a disc, the XMODEM transfer finished but the light on the drive never went off. I waited a while after that and reset the machine and tried to boot from the disc, but nothing happened.....

I wonder if I need some kind of low level floppy test program that I can load in with the HEX LOAD and will write a known pattern to a disc and then have another program read it back.

Going forward, I'd recommend running the ZCB at 9600 baud. Note, however, the DIP switches are notorious for failing over time. Pull the DIP switch from the socket and scrape the pins a bit so you can get a good test with your meter. Verify the 9600 baud switch position clearly goes to less than 1 ohm when you turn it on. If not, flip all the switches hard back and forth a bunch of times. Then see if the contact is any better. If not, you may want to install a jumper wire in the 9600 baud position in the switch socket and leave the DIP switch out for now.

Of course, change Teraterm to 9600 baud and then set the delays to zero. The hex load process works fine without the delay even though the character echo doesn't always look clean.

At 9600 baud with no delays, the disk transfer process is closer to ten minutes or so.

With RAM zeroed, I also get a 0x94 for the 0100 to 0903 checksum, so that is a good reference point.

I'm not sure why a soft reset is needed after loading the hex file, but for now, let's make that part of the "procedure" and figure out why later!

Based on what you have said, it seems your right hand drive is jumpered as drive zero. Drive zero is the drive that PC2Flop writes to. Is the right hand drive also the drive that lights up when you type "B" for boot in the monitor?

Looking at the pictures of your computer, the disk label should face to the left when you insert a floppy into the drive.

PC2Flop should cycle as follows if working normally: First, a full track worth of data is received from the PC via XMODEM, then the track is written. The XMODEM transfer pauses while the track is being written. The track writing operation should be a very noticeable click as the head loads, the track is written and verified, and then the head is unloaded (another noticeable click). The track write operation only takes a second. The XMODEM transfer for the next track should then be obvious on the TeraTerm file transfer dialog box. The XMODEM transfer of data for each track is much longer than the write operation to disk.

After the transfer is complete, you should get a success message from PC2Flop. If instead, control pops back to the monitor without a message, then a disk write failure most likely occurred. The error code, track and sector are save in memory location 0, 1 and 2.

Ahh, the DIP switch thing explains a lot. Every time I have experimented with changing those DIP switches, weird things have happened - like 9600 baud doesn't work, but when I set it back to 1200 that doesn't work for a few reboot attempts, until I mess with the switches a bunch, etc. I'll probably just jumper it for now.

A thought - could the DIP switch package on the RAM card that sets the base address of the card have a similar issue that might have potentially caused some of the intermittent RAM issues that I have seen? Should I stick a jumper where that one is as well?

I did notice the pausing during the transfer even at 1200 baud, but only one "click" of the heads at the start of the process. Not coincident with every pause.

Yes, it would probably be a good idea to measure the DIP switch on the RAM card as well.

I'm bothered by the fact your XMODEM transfer progressed, but you did not hear the heads click for each track transferred. If the write failed, then the XMODEM transfer should NOT have continued. However, if the disk write and verify of a track worked, you should have heard the head unload and then reload for the next track several seconds later.

Which drive lights up when you type "B" in the monitor, left or right?

When I press "B", the right drive lights up.

After switching to 9600 baud and running with zero delays set, let me know if the program behaves differently. You should see the light go off on the drive after each track is written and remain off while data for the next track is received via XMODEM. You should hear the head load and see the drive select light illuminate 77 times over the ten minutes or so it takes to write the disk.

The program unloads the head after writing a track to reduce media and head wear while the next track is being received via XMODEM. This is actually done by selecting drive 3 (which isn't present) since there is no head unload or drive de-select command. If you don't hear the head unload in between track writes or see the select light turn off, then we must have a drive select line problem. This could be caused by a missing or bad terminator on the last drive on the ribbon cable. I have found two bad terminators on these drives in the past. A missing or bad terminator can also cause random drive errors and problems.

Lots of things tonight:

DIP Switches: I checked the DIP switch packs on the ZCB (serial baud) and RAM (base address) cards. Both were....completely dead. Megaohm resistances across the "closed" switches. Flipping the switches didn't help at all. I don't know how either card has been working properly. I jumpered to select 9600 baud on the ZCB and across the address that was selected with the DIP on the RAM card.

9600 Baud: With the DIP switches removed and jumpers installed as mentioned above, the system immediately came up at 9600 baud with no issues. Excellent news.

Right Floppy Drive Issue: I zeroed the RAM, reloaded the PC2FLOP.HEX file, checksummed, reset, checksummed again, and ran the program. When I inserted the disc....... the drive did not start to spin. It seemed to run fine yesterday . I "helped" the spindle a little bit by hand and it did start to move, but when I tried to run the program again it slowed down and stopped when the head loaded. I check the voltages on the mini-regulator board for the drive and +12V was dropping down to +8V when this was happening (a short circuit somewhere?) so it seemed like the right drive is down for the count for now, maybe with some kind of bearing failure?

Removed Drives: I removed the drives and took some pictures. The left drive was relatively clean and the foam pad on the head load arm was intact. The right drive is kind of a mess and the foam on the head load arm is....disintegrated into nothing. I also noted that the drives are different models - the left drive is a 1015 II and the right drive is a 1015 II-B. They are not a matched pair.

Swapped Drive Select: I swapped the Drive Select jumper location to make the left drive the master drive. I also noted that the Drive Select jumpers were tarnished and had a high resistance, much like the other elements of the system that have needed cleaning. I cleaned prior to reinstalling.

Almost-Successful Disk Write: After swapping the drives, I tried to write a disc again. The left drive spun up, accepted the XMODEM transfer, the heads unloaded/loaded with each pause as described, etc. It made it to ~36% before crashing. The 3 bytes at memory address 0, 1, and 2 at this point were 01 00 1B

Further Attempts: All further attempts to write another disc failed, either not accepting the XMODEM transfer, accepting it and going to 100% without the drive doing anything (select light stuck on), etc. I also did some "load attempts" using the Micropolish PDS 4.0 Master Disk I bought. I zeroed memory and ran 'B'. Each time I got the 'G' for good load at address 0x039A, but the contents of the memory from 0x039A-0x400 were *different* each time where I would expect it to be the same since the same procedure was run each time.

Terminator Resistor Pack: I totally missed this until I got home (machine is at a makerspace currently) and started looking at a Micropolis manual. The resistor pack was on the Left drive. So as I purchased it, the machine was mis-configured, with the terminator pack on the Left drive but the Right drive on the end of the cable/selected as master. My re-configuration was also incorrect with the terminator pack on the Left driver, selected as master, but located *in the middle* of the cable. So maybe if I try again with the "working" drive swapped to the Right, at the end of the cable, with the terminator, the results will be better?

I have two of the 1015 drives with bad bearings. Remove the belt and turn the big hub wheel by hand. Does it spin freely, or does it have some resistance or "bumps" as you turn it? Removing and replacing bearings on those drives is not easy! Based on the voltage drop, it could actually be bad bearings in the motor itself. Usually the old dry belts would slip before dragging the motor down that hard.

Going forward, let's leave the right drive unconnected from the ribbon cable and from power. You can connect the left drive with the "middle" ribbon cable connector as long as the terminator is on the left drive.

But first, I'd pull the terminator out of the socket and check it. Clean/buff the pins so you can get a good resistance measurement, then measure from p16 to all pins except p8 and then from p8 to all pins except p16.

The error information in memory locations 0, 1 and 2 shows the operation failed trying to write sector zero of track 27, so the process made it quite a way before failing! Note that the write procedure does a full read-back verify operation as each sector is written. The failure at this point is probably related to timing calibration on the controller board and/or marginal media.

Now that we've gotten this far, we should probably check and recalibrate the timings set by the three pots in the upper left corner of the FDC. It's a quick and easy fix for most FDC problems. See pages 2-1 and 2-2 in the FDC manual.

deramp5113 said:

Now that we've gotten this far, we should probably check and recalibrate the timings set by the three pots in the upper left corner of the FDC. It's a quick and easy fix for most FDC problems. See pages 2-1 and 2-2 in the FDC manual.

Click to expand...

Hi guys!

I haven't had anything to contribute (other than a key, but the OP beat me to it) but I've been following this thread with interest, thanks. It's inspired me to think about revisiting an issue I had a year or so ago trying to use 1.2MB HD drives in my MZs in place of the Micropolis that I could never resolve.

Maybe you can offer some insight but I don't want to hijack the thread; are you on the VG users list by any chance?

Re calibrating the pots on the FDC: how do you go about writing a track 0 of all 'ones'?

My typo -- the three pots are in the upper right corner -- not the upper left! Unfortunately the board silkscreen does not identify the pots, so this should help: From left to right across the top right of the board the pots are R40, R27 and R46.

R40 - sets 1MHz clock, measure at A15P7.
R27 - sets the 2us one shot, measure at B14P5 (easier than A15P5 due to C16)
R46 - sets the 1us one shot, measure at A14P13 (not pin 3 as stated in the manual)

You can see and adjust the one shot outputs without a specific disk pattern written. However, you will need a way to keep the disk reading for a while so you can monitor and adjust the one shots. The good news is that if your drive isn't reading properly, you can probably just hit "B" to boot a disk and the disk will read and read and trying to boot. However, there's a good chance that as you adjust the one shots while the disk is hung trying to get a valid read, that all of the sudden the controller and boot software begin getting valid data and the disk will then complete the boot and stop reading! Once the disk is working that well, you can finalize your adjustments by booting a disk and running a program that reads the disk for a long time (e.g., bad sector search programs, or the DIAG program mentioned in the FDC manual. I have CP/M and MDOS versions of DIAG if anyone needs it.)

By the way, I was able to boot and then configure the very same "Micropolis Master Disk" you purchased to operate on the Vector Graphic MZ running through the ZCB serial port. So when we get your disk drives running properly, we can go through the process of getting your Micropolis Master disk up and running and saved as your System disk.