Re: Can anyone help me with Apple CP/M

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

Paul Schlyter wrote:

> You could reuse the nibble and sector buffers of the "CP/M RWTS" for
> the standard 5.5" drives though: I'll find out where they reside.
> Since CP/M logically uses 128-byte sectors, one had to buffer the
> standard Apple II 256-bytes sectors too.

Well, yes, but that's 256 bytes, not 512. I suppose the UniDisk could be
hacked to do 256k sectoring, but I'd rather be compatible with the
ProDOS
system so the disks can be duplicated by standard utilities.
 
> > 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)
> 
> Not impossible - just harder.  Use a null modem cable, a PC, and
> Kermit, XModem or YModem on both ends... :-)

Yeah - I'm in the process of setting this up anyway. Just have to
transfer
a super serial into the other machine. There's a driver for super serial
on oakland, so hopefully it'll go smoothly.
 
> However, life will certainly be easier for you if you have both 5.25"
> and Unidisks available at the same time!

quite a bit yes :)
 
> > or find somewhere else to hide the routines, ie. Auxiliary memory on
> > a IIe/IIc.
> 
> That could work.  On a standard Apple II or II+ with language card one
> could also use the second 4 KBytes bank in the language card.

I think I'll go the language card approach for now since that'll give
compatability with the II+, and get the system up pretty fast. I've got
my heart set on rewriting the CP/M BIOS now, so when I do that I'll go
for
moving everything possible out of the main memory area to enlarge the
TPA,
and probably code much better support for other devices in the process.
 
> 2 system tracks is the standard value on 8" SSSD disks.  But this
> figure can be configured in the disk parameter table of the BIOS
> (which is described in the CP/M Alteration Guide - no, that guide
> didn't come with SoftCard CP/M, but the standard version works fine
> for the SoftCard too).  Each logical disk (A:, B:, etc) has its own
> disk parameter table - if disk formats are identical, several volumes
> can share the same table I think.

Yep - That's more stuff to squeeze into memory, but I think it'll fit.
When you coded your custom disk support did you leave the standard disk
drivers in place or blow them up ?
 
> So if you don't intend to ever boot CP/M from your Unidisk, I see no
> reason why you cannot configure them for 0 system tracks, and thus get
> a little more disk space for your files.

That's an interesting one. Does the boot drive have to become logical
drive A: in CP/M ? It'd really complicate issues if this happened.
 
> > Yeah I recall that now. A shame; CP/M apps would have been much more
> > portable with decent serial I/O
> 
> They indeed would.  CP/M+ improved this, but unfortunately CP/M+ never
> got as widespread as CP/M 2.2

I've never used CPM/M+ (CP/M 3?). Perhaps one day soon I'll acquire an
applicard
and get it running. What I'd really like to do sometime is get MP/M up
somehow.
If the softcard can live with auxiliary bank switching maybe it'd be
possible.

> > Ok, is that talking in "physical" sectors, or CP/M sector translation ?
> 
> Does this matter if you're going to fill all data bytes on the disk with
> the same byte value?
> 
> Anyway, you might have to consider creating a suitable CP/M sector
> translation table for the Unidisk.  For the standard Apple II disks,
> Apple DOS, Apple Pascal and Apple CP/M all used different sector
> interleaving.  ProDOS used the same interleaving as Apple Pascal.

Yeah I'm set on using the standard Unidisk setup.
 
> > 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...
> 
> True --- I ran the Appli-Card a lot, and enjoyed it.  CPU intensive
> programs really ran about 3 times faster compared to the SoftCard.

I wonder how amenable the Applicard would be to a crystal swap, faster
RAM and a beefy Z80H ? It'd be interesting to see how far it could be
pushed.

I've got a Transwarp in me //e too, so maybe the I/O would be improved
a bit by that, presuming the 6502 side software doesn't have timing
issues.
 
> > 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 think they re-wrote CP/M itself, to make it runnable in that bank
> switched environment.  To applications, the TPA was still un-banked.

Ah, probably just shunted their BIOS into the 2nd bank so than the BDOS
could load higher. I guess in that sense it's not really a 60k system,
just a neater version of the 56k system, since the linear memory
available
to the Z80 doesn't really change.
 
> > I wonder if the standard 56k system uses the 2nd bank for anything..
> 
> Nope!
> 
> > If it didn't that'd provide the perfect spot for the Unidisk support.
> 
> Precisely!

Wicked wicked wicked. Trust microsoft to waste an enormous area of
memory :)
This should be nice an easy once you dig out that info !

Cheers,

Matt