[net.micro.cpm] Compupro 8088/85 processor.

MMOON.ES@PARC-MAXC.ARPA@sri-unix.UUCP (10/03/83)

I am considering taking the plunge into the "16" bit world by trading in
my old reliable Cromoemco ZPU for the 8088/85 board from Compupro.  I
sprung for the manual at Priority 1 & found out the initial conversion
will cause no real shock waves from the hardware standpoint.  However,
the 8085 will become the main processor in the short run, meaning I have
to give up my ZCPR2 implimentation.  I seem to remember some discussion
on this net regarding 8085 versions of at least the utilities &
hopefully the CPR itself (obviously with a little cutting).  I would
appreciate a list of the files to look for & a pointer to a non-ARPA, i.
e., *not* SIMTEL-20, source as 1) We at Xerox without clearance have
message-only access to ARPA-net with *no* FTP capability & 2) The local
RCPM's haven't breathed a word I've been able to find on the subject.

For long term, I have another question.  Am I tied to the Compupro &/or
G&G CP/M-86 or MP/M-816 software?  My disk controller is a Morrow DJ2DIO
which is out of production, I believe, but has been quite reliable.  I
don't want to spring for a Disk-1 while I have a perfectly good floppy
controller, but this poses some obvious problems with a roll-your-own
BIOS for either of the above OS's.  Anybody been through this before I
re-invent the wheel?

Thanks in advance for *any* info.

		MMoon.es

strom@brl-bmd@sri-unix.UUCP (10/04/83)

From:      Charlie Strom (NYU) <strom@brl-bmd>


Let me address the question of running ZCPR on the 8085. I converted
Rick's replacement CCP and several of the utilities that used Z80 code
with little effort thanks to his code commenting and the macro structure
used. The conversion is available on SIMTEL20 as well as in a SIG/M dis
(volume 12n?) It is rather easy to determine which SIG/M disk from
asking around a little - sorry, but my latest SIG/M listing is at the
office. I also have the appropriate files up on COmpuserve's CP/M interest
group (CP-MIG).
The tight space limitation forced me to eliminate SUBMIT processing in my
implementation, though if that is a must, I'm sure other features could be
sacrificed instead.