PDA

View Full Version : Kaypro 4 - boot floppies get corrupted...?



mcfuzz89
October 8th, 2017, 12:32 AM
Hi all,

I acquired a Kaypro 4 a few months ago - unit appeared to be in excellent condition and, at the time of acquisition, it booted off the factory (!!!) boot disks without a problem. I've put the unit in storage for a few months and literally this past Friday decided to pair it to my Raspberry Pi 3 to use as a terminal.

Everything worked fine this past Friday - it'd boot off the floppies no problem, but I had to do a lot of trial and error to get connected to my Pi - eventually I succeeded and called it a day.

This morning, I inserted the same floppy I used yesterday (CP/M 2.2G boot disk), fired the Kaypro up but instead of loading the floppy, it started doing 11 rapid clicks which repeated a total of 4 times. After, I got a message reading BDOS: Err on A/B: Bad Sector. Interestingly enough, I could still launch programs but if I wanted to review directory contents, it'd do the same
11 clicks cycle.

I tried another boot-disk and it worked fine... at first... then the same issue. Seems to occur on both A and B drives so it does not appear to be a drive issue... controller perhaps? Or maybe something I am missing? So far - 4 floppies started exhibiting these issues... including one that I've never used before.

Any suggestions would be greatly appreciated!

ldkraemer
October 8th, 2017, 03:24 PM
The one "Fly in the Ointment" of CP/M is that the system doesn't know when you change a floppy out. So, when you
Replace a floppy from the A: or C: Prompt, you need to do a CNTL C to Warm Boot the system. This will read in
the Current floppy(s) directory information. You can also do a Hard RESET with the RESET Button.

If you don't do a warm boot, the next time you write to a floppy the previous floppy's directory information is updated
on the floppy that is currently in the drive. It just gets clobbered.

Not to worry, just reformat those trashed floppy's, sysgen them, and copy the files with PIP or NSWEEP.

The other possible thing that is happening is that the oxide coating on the Floppy's is OLD Enough to be coming off
the Cookie and getting deposited on the Read/Write Heads. If this is the case, remove the Floppy Drive, disassemble
it by removing the logic board (Read/Write Head Connectors) and gently clean the head(s) with a cotton swab dipped in
Alcohol. Then re-assemble. Takes less time to do it than write how to do it.

Larry

mcfuzz89
October 8th, 2017, 03:37 PM
The one "Fly in the Ointment" of CP/M is that the system doesn't know when you change a floppy out. So, when you
Replace a floppy from the A: or C: Prompt, you need to do a CNTL C to Warm Boot the system. This will read in
the Current floppy(s) directory information. You can also do a Hard RESET with the RESET Button.

If you don't do a warm boot, the next time you write to a floppy the previous floppy's directory information is updated
on the floppy that is currently in the drive. It just gets clobbered.

Not to worry, just reformat those trashed floppy's, sysgen them, and copy the files with PIP or NSWEEP.

The other possible thing that is happening is that the oxide coating on the Floppy's is OLD Enough to be coming off
the Cookie and getting deposited on the Read/Write Heads. If this is the case, remove the Floppy Drive, disassemble
it by removing the logic board (Read/Write Head Connectors) and gently clean the head(s) with a cotton swab dipped in
Alcohol. Then re-assemble. Takes less time to do it than write how to do it.

Larry

It is quite possible that it's option 1 that I am suffering from...

How would I go about doing sysgen? I am a complete CP/M n00b but suspect I need a valid boot disk, no?

Chuck(G)
October 8th, 2017, 04:20 PM
My initial vote is for shedding oxide. It can really make a mess of things.

mcfuzz89
October 8th, 2017, 07:00 PM
My initial vote is for shedding oxide. It can really make a mess of things.

But other floppies (for example wordstart, dbase, etc) load without any issues...

MicrocomputerSolutions
October 8th, 2017, 08:59 PM
The other common mistake that many people make is leaving the floppy disk/s in the drives when shutting the system down. This can cause a glitch in the recording on the floppies as the power goes down the drive's heads sometimes write or erase. Always open the drive doors and pull the disk at least partially out of the drive/s before shutting down the power.

And don't insert disk/s into the drive/s until after powering up.

mcfuzz89
October 8th, 2017, 10:30 PM
The other common mistake that many people make is leaving the floppy disk/s in the drives when shutting the system down. This can cause a glitch in the recording on the floppies as the power goes down the drive's heads sometimes write or erase. Always open the drive doors and pull the disk at least partially out of the drive/s before shutting down the power.

And don't insert disk/s into the drive/s until after powering up.


Good to know - thanks!!

ldkraemer
October 9th, 2017, 03:35 AM
mcfuzz89,
The command to format a NEW Fresh Floppy is:
FORMAT B:
Assuming you have a boot floppy in A: that contains the program FORMAT.COM. Some Kaypro systems have updated EPROMS
and have a configure program and new format program. You will have to search for the program that formats a SPARE Floppy in B:

After the Floppy is formatted, to make it bootable just run the command:
SYSGEN
The system will ask you for the Drive containing the SOURCE DISK, which contains the Boot Track(s). You answer with A (or B)
and then it will ask which floppy contains the DESTNATION FLOPPY. You answer with B (or A)

If PIP is also on the Boot floppy (or NSWEEP) you can copy all files to the NEW FLOPPY (After a CNTL C) (of course) with:
PIP B:=A:*.*[ov]

PIP Dest:=SRCE:*.COM[ov] DEST=A: or B: or C: or D: SRCE:=A: or B: or C: or D: and the OV means O Object File Xfer & V means VERIFY

If you want to copy PIP from A: to B: you need a special trick to copy it. The commands are:
B:
A:PIP B:=A:PIP.COM[G0]
Which will copy PIP.COM from User 0 on A: to B: User 0

There are 15 User Areas on each floppy. A{0..15}
So, you may find files in A): or A1: or A8: for A15: Same for B0, B1: B2: ........
The DEFAULT is USER 0.

If A0: is the logged Drive you can change to User 5 (prompt shows A5>), you can do the following:
USER 5
B:

The logged Drive becomes B5:
B5>
DIR *.* will show the Files.


Larry

geneb
October 9th, 2017, 05:39 AM
One good thing to do when you get a vintage system like this is to make duplicates of all the "important" disks you got with the system, right away. Original media like that tends to be a ticking time bomb - it's not a matter if it's going to fail, but a matter of when.

g.

durgadas311
October 9th, 2017, 10:04 AM
Note, CP/M does a pretty good job of avoiding corruption of a disk when you swap them unexpectedly. CP/M *does not* store directory information in memory, and so it will *not* clobber the directory of a disk if you swap around. CP/M does maintain a checksum vector of the directory in memory, and every time it reads a sector of directory (which it must do before writing), it will check the checksum and set the disk to read-only if they don't match. This is not to say you can't corrupt a CP/M directory, but just swapping diskettes around is not likely to cause that. Now if you swap disks while a program is running, you can get some corruption - until the program does an operation that requires directory access. But that will not corrupt the directory, "just" the data on the disk after the directory.

It is true that you must do the ^C to reset the drive "login" bits, to force a fresh computation of directory checksums. That is the recommended procedure. If you are swaping drive A:, one most CP/M 2.2 systems, you will need to ensure that the new disk has the system written to the boot tracks since ^C will cause a re-read of some of the system (typically BDOS, and CCP).

Chuck(G)
October 9th, 2017, 10:14 AM
Almost true--disks that are identical in the first CKS (determined by the BIOS) directory entries will be treated as the same disk, regardless of what might be in subsequent directory entries. That can possibly lead to grief if your habit is equipping every new floppy with a fixed set of utility programs.

durgadas311
October 9th, 2017, 10:23 AM
Yes, that is true - there are some situations that CP/M does not detect the disk change. But that should not corrupt the directory of the second disk (assuming you are not switching disks while a program is running). I also should go back and actually read the full discussion up to this point, so I can get a better idea of what actually happened. I just wanted to address the idea that CP/M was going to wipe out the directory just because one swapped disks.

mcfuzz89
October 9th, 2017, 10:27 AM
Almost true--disks that are identical in the first CKS (determined by the BIOS) directory entries will be treated as the same disk, regardless of what might be in subsequent directory entries. That can possibly lead to grief if your habit is equipping every new floppy with a fixed set of utility programs.

I think that is what hosed me; the floppies I was cycling through were different iterations of CP/M core utilities... Lesson learned!

The sad part is that when I tried formatting one of the floppies, it got all the way to track 79 and then spit up a bad sector error :\