I previously posted on the possibility of (ab)using an Atari 1050
disk drive to connect to a homebrew Z80 SBC. I was disheartened
to learn my 1050 is most likely suffering from a blown LM3086
transistor array :^(
This left me in a bind, as the 1050 was a means to an end, and
not the end itself; the end, of course, being bringing up CP/M 2.2
on hardware of my own design and construction ( a decade long
endeavor for me - I may not be good, but I sure am slow...)!!!!
So, I turned to the veritable swiss-army knife that is GNU/Linux.
I chose Debian 5 (Lenny), running on an older Dell Dimension
(512MB RAM, 1GHz Intel PIII) which had an external DB-9
serial port available.
I wrote a program which emulates an IBM-style drive-
77 tracks, 26 sectors per track, 128 bytes per sector;
it is written in ANSI and POSIX compliant C-89 (I think).
The program was inspired by APE, SIO2PC, and other programs
which access 8-bit disk drives over serial (and sometimes
parallel, and sometimes _both_) ports. I defined a semi-custom
communication protocol, which closely resembles that of the Atari
The results have been most gratifying :^) The system will not win
any speed contests- checksumming each sector on the SBC slows
down reads quite a bit- but it _works_. Well, so far, anyway....
I used the CP/M 2.2 sources, in Z80 menmonic format from:
I chose to cross-develop with SjASMPlus; it took everything I
threw at it in stride, and has only one or two minor quirks.
Of course, I had to bootstrap the whole shebang with a monitor,
which I wrote from scratch. It is menu-driven, verbose, and thus
a little bloated, totaling just under 4KB. It features:
- XMODEM file download to selectable address
- dump ASCII text files to screen w/ paging forward/reverse
- hex dump RAM, 256 bytes per screen w/ paging (forward only)
- load/save CP/M system image to/from "system tracks"
- jump to TPA (0100h)
- jump to BIOS (0FA00h)
The hardest part of the whole affair was getting the BDOS to work
with my CBIOS. I basically manually transcribed the "Appendix C:
A Skeletal CBIOS" from the DRI docs. Initially, it highlighted
several bugs in my Virtual Serial Drive (VSD for short). Then, CP/M
choked on my zero-filled image- which I fixed by learning where to
to stuff 0E5h ;^) But, then, inexplicably, the BDOS began choking
and throwing fits on SAVEing files from the TPA. As getting programs
into the TPA from my PC involved bouts of SBC reset, XMODEM,
and then 'lukewarm boot', this was the source of much weeping
and gnashing of teeth... I finally traced the cause to a patch, which
resolves an issue the BDOS had with deblocking. I reverted the
patch, and voila! Programs could be SAVEd at will, and I now have
a bootable image which contains:
M80, L80, ZSID, PIP, ED, STAT, LS
[ LS.COM was borrowed rom Schorn's AltairZ0 CPM2 package :^) ]
The patch issue stems from the fact that by correcting a
deblocking issue, it breaks a CBIOS which does _not_ implement
deblocking. At one point, I manually transcribed the deblocking
routines from Appendix G, but for some odd reason, the CCP
refused to start, and I was unable to diagnose the source of that
Someday, I will get this info uploaded to a website. But, in the
interim, I wanted to share my experiences and thank everyone here
for their time, and effort, and knowledge.
 or is it Intel/MDS? I guess the Intel/MDS was a controller
'in front of' the IBM drive?
 I actually have a hardcopy Kapro II manual - with a big
thumbprint from someone enlarged on pg 29!
 loading the CP/M system image from the system tracks
while in the monitor, and then jumping to the CBIOS.
 the original code:
DCR C ; DEC C
DCR C ; DEC C
JNZ WTSEQ99 ; JR NZ,WTSEQ99
LXI H,0 ; LD HL,0