A number of websites have archived CP/M distributions with the single density Tarbell controller custom BIOS (CBIOS.ASM) and boot (CBOOT.ASM) files. These required minor changes initially and provided a reasonable base for generating subsequent CP/M disks. 

I started by editing the system tracks of the disk images, then writing the images to physical media using my disk imaging workstation. The BIOS assumed a console output using the MITS 88-2SIO at ports 10h/11h. I needed to change the ports and RDA/TBE values to correspond to my hardware. I also discovered that my drive controller was set up a bit differently than the default Tarbell settings. The controller uses six I/O ports starting (normally) at F8, but my controller wouldn't respond. The controller has a small 82S123 PROM for an initial bootstrap loader that starts at $0000 on a machine reset. Basically, the bootstrap is executed from the PROM and is supposed to load the first sector of the disk.  Hand dump of PROM on Tarbell using the front panel showed that mine was set up to use ports starting at E8, a configuration that was available from Tarbell for the Processor Tech Sol 20, which had an I/O conflict at F8—I think for the video controller. Here's a dump of the ROM:

0000: DB EC AF 6F 67 3C D3 EA 

0008: 3E 8C D3 E8 DB EC B7 F2

0010: 19 00 DB EB 77 23 C3 0C

0018: 00 DB E8 B7 CA 7D 00 76

  0000  IN   EC  ; wait for intrq or drq

  0002  XRA  A  ; sets A to 0

  0003  MOV  L,A  ; set HL=0000

  0004  MOV  H,A

  0005  INR  A  ; set sector to 1

  0006  OUT  EA  ; 

  0008  MVI  A,8C  ; read sector command

  000A  OUT  E8  ; issue command to 1771

  000C  IN   EC  ; wait for intrq or drq

  000E  ORA  A  ; set flags

  000F  JP   0019  ; done if intrq

  0012  IN   EB  ; read byte from controller

  0014  MOV  M,A  ; store at HL

  0015  INX  H  ; advance one byte

  0016  JMP  000C  ; read next byte

  0019  IN   E8  ; read disk status

  001B  ORA  A  ; set flags?

  001C  JZ   007D  ; go to sboot if zero

  001F  HLT             ; error - halt

1. Initially, small transient programs like XDIR and STAT worked, but larger ones like PIP, DDT, FORMAT, COPY, and ED didn't. After much mussing around, I switched the order of my 8K RAM cards, and at least COPY worked. The RAM checked out by the front panel and the memory check routines in the old monitor program that I used previously. By PIP copying DDT, I then compared dumps of the original version and its copy. PIP loads at 0100 and the last address loaded is 2200. Assuming that the buffer used to read / write is after this, then adding the first error address (difference between the original ddt.com and the copied file) to this should give the location of any bad memory. Based on this idea, 2200+0E00 = 3000 and the last error occurs at 2200+1180=3380. Each error I noted was a value +/- 4 of the original, so it did indeed look like a bad bit (chip DE3, in this case). It must be in bank CE4. Replacing this 2102 chip on the IMS board finally got these programs working—except for persistent PIP problems copying between drives (more on this below in 5).
2. As I worked though this problem and others, I spent a lot of time worrying about skew and I tried many skew settings when writing images. But it turns out that the Tarbell controller uses a skew of 6 and the WD1771 controller deals with the translation from the sequential physical to the skewed logical sectors. 
3. Shortly after the above adventures, I started rolling CP/M on Udo Munk's 8080 / Z-80 emulator—compiling BIOS.ASM and BOOT.ASM. By then, I had a version of Martin Eberhard's XMODEM running to move files, and I had enough functionality with DDT that I could SYSGEN then patch the existing CP/M with the compiled HEX files. (I could also transfer patched copies of CPM.COM for writing.) That eliminated the need to edit disk images directly and write them with the disk imaging workstation.
4. A few months later, the computer was working fine. But then something happened—a bus conflict? The serial port was dead. I thought it was the 3P+S. The disks were acting up. I couldn't boot anything—it sometimes read, sometimes didn't. Disk activity became erratic. No disk booted on either controller (I was also testing a ThinkerToys Disk Jockey at the time), although the head would load. I verified that the 3P+S was working. I entered the simple serial loader and transferred the monitor to 1C00. It ran fine. I took out the Tarbell controller. Bit 2 (4) is coming on in the first 1K and staying on. It could have been a bad 2102 on the first memory board. Which chip? I switched out U4 with a replacement and that took care of the problem. U4 is the first row (top) chip 3 from the left. Both disk controllers were up and running again. MEMORY was the problem! Again! It's curious that sometimes memory fails or is marginal under CP/M but otherwise works through the front panel or a simpler monitor. 
5. My biggest mystery: Running CP/M 1.4 (2-15-78) using the Tarbell single density controller BIOS, I had persistent PIP failures when copying files from drive A to B, and sometimes back. Most of the time the first sector's worth of data of the copied file was E0 or 00. The rest looked ok. At first I thought it was reading the the wrong sector (or wrong track) when it started. Was it software or hardware? And it wasn't just PIP. Using ASM to compile a file like 'ASM format.abb' resulted in garbage in the files written to drive B. After a lot of troubleshooting and yet another pass through the BIOS, 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—they were "sharing" the same entry, which led to track verification errors. 
6. Drive B was pretty glitchy. My first repair job on J1 was probably sub-par, but the fact that the wires were cut may have also indicated another problem. Well, drive B started acting up (repeated head load / unload when trying to write or read), but jiggling the J1 jumper would often get it to work. I re-patched the J1 connections, and this seems to have solved the problem. If it acts up again, I'll check whether the J1 pins on the logic board have cracked solder joints.
7. I also have a ThinkerToys Disk Jockey I controller. I spent some time getting it running, but it was a lot slower than the Tarbell 1011A, so I gave up on the idea for now. I might eventually get it running with the Z-80 board as an alternate configuration of the machine. Maybe I'll even migrate to CP/M 2.2.