PDA

View Full Version : Also: persistent PIP problems



ef1j91
May 25th, 2017, 06:06 PM
Running CP/M 1.4 (2-15-78 ) using the Tarbell single density controller BIOS, I've had persistent PIP failures when copying files from drive A: to B:. Most of the time the first sector's worth of data of the copied file is E0 or 00. The rest looks ok.

I'm guessing that this means it's initially reading the wrong sector (or wrong track) when it starts? Anyone else ever experience this persistent PIP problem?

JonB
May 26th, 2017, 01:58 AM
Since PIP is a transient program, you could try to put a copy from a different CP/M onto it. Yours may be corrupted.

(Long shot, I know!)

ldkraemer
May 26th, 2017, 02:56 AM
Try the followinf Pip command to copy your files:
PIP DEST:=SOURCE: [switches]

switches:
o = Binary type copy
v = Verify after copying

PIP B:=A:*.* [ov]

Version 1.4 could be slightly different, so if that doesn't work try:
PIP B:=A:*.*[ov]

Good Luck!

Larry

ef1j91
May 27th, 2017, 08:56 AM
These are good suggestions. The PIP I am using is VER 1.33. I seem to be able to copy from B: to A: ok. Sometimes. When a file is corrupted, it looks like the first sector of the file isn't written. Either that or the directory is corrupted.

I confirmed that the PIP.COM I'm using isn't corrupted.

A command like 'PIP con:=file.txt' works fine.

It's not just PIP. Using ASM to compile a file like 'ASM format.abb' results in garbage in the files written to B:

Must be a hardware issue? Very puzzling.

Chuck(G)
May 27th, 2017, 09:08 AM
Hardware or software? What you describe with 8" drives is usually the result of not allowing the head to settle after a head-load has been engaged. That drive head bounces a bit when loaded--if you don't allow time for the bouncing to die down, you'll get corruption on the first read or write. You can also get a similar effect if the head isn't allowed to settle after a seek.

If the Tarbell FDC is the one that I have (uses a WD1771 FDC) and has lots of wired jumper pads, I'd be willing to take a look. I had no problems with mine, but I wrote my own BIOS.

ef1j91
May 27th, 2017, 09:45 AM
I've been using the Tarbell BIOS at deramp.com with minor modifications (mine came with a ROM set up for I/O ports starting at E8 instead of F8.) I'm willing to bet it is hardware, but some disk operations work fine. I can copy and format disks, for instance.

I like the idea of the head not settling. But I'm not sure why I don't see problems copying of formatting.

Chuck(G)
May 27th, 2017, 09:56 AM
Is the issue intermittent? Does PIP always mess up the first sector, or is it just occasional? Does the first sector get bollixed if you're copying a file to another file on the same disk?

What are you using for floppy drives?

ef1j91
May 27th, 2017, 06:52 PM
It seems to be very intermittent. I made a new copy of CP/M with all of the files transferred over by XMODEM. Then I formatted a new disk and copied the files to it with PIP (e.g. PIP b:=a:*.*) All of the files transferred fine except one, which was my BIOS ASM file.

I'm using Shugart 800's. I've switched them around, etc. That doesn't help or make the problem worse.

It would be helpful to understand the internals of PIP, and I should double check that the Tarbell jumpers haven't come loose. I had to do a few trace repairs when I got it---it was set up for Z-80 operation.

Chuck(G)
May 27th, 2017, 07:48 PM
That's easy - here's the PL/M source to PIP. In the case of a file-to-file copy, you want to look at the "SIMPLECOPY:" routine.

There's not much to it--and it works the way you'd expect.

I think you're barking up the wrong tree, however.

deramp5113
May 28th, 2017, 05:50 AM
I agree, definitely not an issue with PIP, it's a hardware problem. Lots of possibilities to work through, of course. Since disk I/O with minimal head movement and load/unload (e.g., format and track by track disk copy) is more reliable than "normal" disk I/O by PIP or ASM, I'd focus on head load or track movement errors as noted by others.

From what I recall when trying out the Tarbell CP/M 1.4 versions, head load/unload occurs very frequently - even when it seem it shouldn't have to. Many of those load/unloads were just a fraction of a second apart. I'd take a look at the head load pad thickness on the drives and also see which hole/tab the head load spring is connected to. The spring should attach to the proper hole/tab based on the orientation in which the drive is operated (e.g., flat, edge, vertical, etc.). Note that flat with PCB up is not a workable option for the Shugart 800's.

The 1982 CP/M 2.2 for the Tarbell reduced head load/unload dramatically over the 1.4 versions. The track buffered version of CP/M 2.2 reduces head load/unload even further and is much faster.

Mike

Chuck(G)
May 28th, 2017, 08:04 AM
For testing purposes, there's probably nothing at all wrong with permanently grounding the HEAD LOAD line. Most 5.25" drives and all 3.5" drives operate with the heads perpetually loaded.
------
I'll add that grounding the HEAD LOAD pin on each drive does not necessitate removing wires or reworking your cables. The SA800 lines are driven by open-collector (usually 7438 ) drivers, so grounding them will not cause you to blow out a circuit.

ef1j91
May 28th, 2017, 12:04 PM
This has been absolutely fascinating. The Tarbell 1011A with CP/M 1.4 does execute a lot of head load movements. I'll have to post a video of it. It really chatters.

Even the format and copy programs I am using load and unload the head for each track read / write. I guess the difference is that there aren't multiple track seeks like PIP and ASM. They're just stepping to an adjacent track.

Chuck(G)
May 28th, 2017, 12:21 PM
It's largely a function of the BIOS and the way it's employed by CP/M, not the controller.

I might have a copy of my own CP/M BIOS with the 1011A kicking around, if you're interested. It'll be about 40 years old, but the coding should still be okay, assuming that the floppy's still readable. The 1101 is hugely configurable, so you can likely change the way the head-load is managed.

Just curious--why CP/M 1.4? 2.2 has a lot more functionality for not much more memory.

ef1j91
May 28th, 2017, 12:55 PM
I'd really appreciate a copy if you track it down.

To answer your question, I've been mainly interested in what someone might have experienced in the early days of microcomputers. The limitations and bugs are sometimes as interesting as the capabilities in these machines. Of course, with 40 year old hardware, I'm not always sure it's an authentic enterprise. It's sometimes difficult to separate the hardware limitations from age-related failures.

Chuck(G)
May 28th, 2017, 03:06 PM
Gaby's got the binaries here (http://www.cpm.z80.de/binary.html) of course.

Are you referring to not having a ready-made copy? Does Deramp have one?

ef1j91
May 29th, 2017, 03:31 PM
I've been using the Deramp images, although generally rolling my own CP/M from them. I did start off a while back directly editing the disk image (I'm using different addresses for the serial I/O and my Tarbell is set up for E8 ). I also grabbed the Gaby copies. Lately I've been assembling BIOS in an emulator like z80-pack then patching the CP/M on my IMSAI with the HEX files.

I was looking at an image of a corrupted disk I made yesterday. I SYSGEN'd a new system and PIP'd over all of the usual files. All transferred successfully except one, which was "missing" it's first sector. It should have been written to track 13 sector 9 according to the record table. It ended up being written to track 0 sector 9. So THAT error sounds a lot like the one documented in the Deramp site where a seek error returns the head to track zero then reads (writes?) to the wrong track.

Chuck(G)
May 29th, 2017, 05:35 PM
That sounds like a software bug. I'm assuming that seeking is setting the "V" flag (bit 2) in the seek commands.

ef1j91
May 30th, 2017, 05:35 PM
VICTORY!

Another pass through the BIOS and I realized that the option "DUAL" set to TRUE was the cause of the problems. I hadn't grasped the meaning of this setting earlier, but as a result the drives weren't using their appropriate entries in the disk track table. No wonder I was getting track verification errors.

The sucker still clanks away with head loads and unloads, but I successfully assembled the BIOS on drive A: and wrote the HEX and PRN files to drive B. LOOKS GOOD! Thanks again for the help!

ef1j91
August 7th, 2017, 05:50 PM
Got around to posting a video of the computer assembling Martin Eberhard's XMODEM under CP/M 1.4. The file is about 72K. The real fun starts after the assembly, when the executable is created from the HEX file with LOAD. The activity of the drives / heads is pretty outrageous.

https://youtu.be/JOdOKMO-g6w