Re: Can anyone help me with Apple CP/M

[Matt Jenkins <mdj@pacific.net.au>]

Paul Schlyter wrote:
 
> So you might be able to squeeze it into $0300-$03FF then?

Unfortunately not. I did a bit of research last night and discovered
chapter 6 in the CP/M 2.2 manual gives much information on how the disk
system in the CP/M BIOS operates. For the Unidisk 3.5", presuming the
Smartport
firmware is used to communicate with it, I'd need 512 bytes as a disk
block buffer,
plus room to fit modified blocking routines for CP/M sector translation,
so unfortunately
it seems I either replace the existing disk framework with 3.5" only
support (which would
be okay except for the fact it'd make getting data on/off the 3.5" disks
impossible) or find
somewhere else to hide the routines, ie. Auxiliary memory on a IIe/IIc.
 
> > How much detail does the softcard documentation go into on the boot
> > process?
> 
> It gives no information at all.  But you can disassemble the code and
> look at it.

Okay... Does the CP/M system use 2 or 3 tracks on a disk reserved for
the OS ?
The CP/M docs say 2, but I'm guessing the Apple versions use 3 ala DOS
3.3
 
> Don't worry about the serial port drives.  CP/M 2.2 had lousy support
> for serial ports anyway, so any real application talking to the
> serial port (such as Kermit) will have to be modified to talk
> directly to the serial port hardware.

Yeah I recall that now. A shame; CP/M apps would have been much more
portable
with decent serial I/O
 
> I'll look for info regarding hooking up new disk drives to the SoftCard
> CP/M.
> 
> Then you'll also need a way to "format" the 3.5" Unidisks.  You could
> write that "disk formatter" to run under DOS 3.3, ProDOS, or
> whatever.  All it needs to do is to write $E5 into each and every
> byte of each and every sector of the disk.  That's it!  To CP/M,
> sectors filled with $W5 are acceptable as an empty root directory.
> You cannot boot from these disks, of course, but let's assume you
> boot from 5.25" disks anyway, so you don't have to worry about the
> system tracks.

Ok, is that talking in "physical" sectors, or CP/M sector translation ?
Writing an app to $E5-ify an entire 3.5" disk is simple enough to do.

> The Appli-Card had it's own 64K of RAM, so Appli-Card CP/M was a 63K
> CP/M system (1K was needed for housekeeping stuff).  Since the Z80
> and the 6502 each had their own RAM on the Appli-Card, the two
> processors needed a way to communicate.  This was done via the Z80
> ports, which mapped to RAM addresses as seen by the 6502: a protocol
> was run in the Appli-Card system which enabled the Z80 and the 6502 to
> "talk" to one another.  Since the Appli-Card Z80 was unable to access
> 6502 memory at all, *all* I/O stuff had to be done via the 6502 in
> the Appli-Card.

Interesting. That would've resulted in a board that had very nice Z80
code
execution performance, but it might've taken an I/O hit...
 
> Then there was the CP/M Card, which ran CP/M+ aka CP/M 3.0.  The CP/M
> Card implemented memory banking, where the first memory bank was the
> CP/M Card's own 64K RAM, and the second memory bank was the 6502 RAM...

That would've been the Cir-Tech boards if I'm not mistaken. That system
already
provided all the support I've been dreaming of. Nice cards.
 
> FInally, to return to your question: yes, there was a 60K CP/M system
> for the SoftCard too.  It appeared fairly late, and it seems to have
> been using that second 4K RAM bank on the Lanugage/RAM card of the
> Apple II to gain another 4K of RAM.

That's interesting. That second 4k was accessed by switching out the
D000-DFFF
range (4k bank 1), so one wonders how they provided both 4k banks to the
Z80, and
what they decided to remove; The 0000-0FFF range or the C000-CFFF range.

I wonder if the standard 56k system uses the 2nd bank for anything.. If
it didn't
that'd provide the perfect spot for the Unidisk support.

Was this Microsoft supplied and/or did it work with the standard
softcard?
I'd be interested in acquiring disks for that system... It's too bad
there's no
ftp archives with Apple CP/M stuff out there.

Thanks,

Matt