paul@athertn.Atherton.COM (Paul Sander) (10/10/88)
I own an old Apple II Plus system into which I have installed a "CP/M Card [TM]"
from Advanced Logic Systems. The Card runs CP/M 3.0 in a banked memory
configuration.
My application is a disk conversion program which will move files to and from
CP/M and Apple DOS 3.3 formats. It seems that making BIOS calls will not
work properly when accessing the disk, as most of the BIOS related to disk
activity reside in the bank opposite the application code.
I have tried setting my disk access parameters by calling the BIOS SELDISK,
SETTRACK, SETSECTOR, SETDMA, SELMEM, and SETBNK routines before calling READ.
The result is that this sequence of calls will in fact transfer the data into
my buffer if it happens to be in the area of memory that is shared between the
two banks (no surprise).
There are two reasons why I don't use the code that works: First, SID is
loaded into the part of memory that is shared between banks, so my broken
program breaks worse under the debugger; second, my programming environment
(one of the C implementations) makes it hard to allocate my transfer buffer
in the shared memory area as that is where the stack resides.
Has anyone solved this problem? Or does anyone have any suggestions for
anything I have left out?
Second, I see that the BDOS provides a "DIRECT BIOS CALLS" function which
takes as a parameter the address of some sort of parameter block which
presumably contains parameters that are loaded into registers before calling
the BIOS. Does this facility overcome the bank dependence of the BIOS?
What is the format of this parameter block?
None of the literature I got with my Card has the information I need. Neither
does the application note describing ALS' banked memory implementation, nor do
the other CP/M books I've bought over the years.
Any help you could give me would be much appreciated.
Many thanks in advance,
Paul Sander
paul@athertn.Atherton.com
{decwrl,sun}!athertn!paulgalew@hpsmtc1.HP.COM (Gale Wolfenbarger) (10/10/88)
Boy have you ever stepped into a can of worms! I'm not sure if I can help you or not but I'll try. I did the last 3 or 4 releases of the als BIOS for the CPM Card but that was about 3 years ago and things are pretty fuzzy about it now. First if you have the version of the als CPM that works with ProDos you are in. With it you can make calls to ProDos and ask it to read files for you. As I recall there is a utility in ProDos to convert DOS to ProDos files. This is still not simple but a whole lot easier than the alternative. I don't have the documentation on how to do this with me but it involves a couple of extra entry points that I put in the BIOS for just this purpose. als should be able to supply those entry points for you. And if not...(sigh!) I'll try. If you don't have the ProDos version, all is still not lost as there are two other entry points that I added to read and write single bytes to and from Apple memory. So if you made a RWTS call to read the sector from the apple diskette, you can get the information from apple memory a byte at a time. Finally, it is possible to make BIOS calls through BDOS by using function 50. (I think that is the right number). This function was designed for this purpose. It will return to you a pointer to your data in CPM memory where you can get to it. It does all the bank switching and copying for you. Remember though, interleave between CPM, DOS, and ProDos are all different. (It's enough to make you scream!.) als is generally pretty good about answering questions when you can get through to them. And when they can't eventually I hear about it. At one time I had documented all the new entry points and how to use them. But that was years ago and you know how turnover is. I know this is all very vague, but I warned you at the outset that is was messy. I hope that it helps. By the way I am a consultant and in your area. If worse comes to worse I'll try to dig out my old CPM stuff. Happy digging. Gale.
paul@athertn.Atherton.COM (Paul Sander) (10/17/88)
In an earlier posting, I mention a problem I am having accessing the disk directly through the BIOS provided with my CP/M Card [TM] installed in my old Apple II Plus. I have not had complete success after calling SELDISK, SETTRACK, SETSECTOR, SETDMA, SETGNK, and finally READ via the BIOS. In Message-ID <11670001@hpsmtc1.HP.COM> galew@hpsmtc1.HP.COM (Gale Wolfenbarger) writes: >Boy have you ever stepped into a can of worms! Well, I don't know. It seems manageable to the well-informed. > I'm not sure if >I can help you or not but I'll try. I did the last 3 or 4 >releases of the als BIOS for the CPM Card but that was about 3 >years ago and things are pretty fuzzy about it now. I'm pleased to make your acquaintence. I'm sure that anything you say will be very helpful. > First if >you have the version of the als CPM that works with ProDos you >are in. With it you can make calls to ProDos and ask it to >read files for you. As I recall there is a utility in ProDos >to convert DOS to ProDos files. > [Stuff deleted mentioning details about this conversion method] My CP/M Plus revision level for the CP/M Card [TM] is 3.01C2, about 3+1/2 years old. It came with some Prodos utilities, but I don't have Prodos. >If you don't have the ProDos version, all is still not lost as >there are two other entry points that I added to read and write >single bytes to and from Apple memory. So if you made a RWTS >call to read the sector from the apple diskette, you can get >the information from apple memory a byte at a time. The good folks at ALS sent me a copy of Mark Howard's application note describing the APRD and APWRT calls. The problem with this method is that I have no documentation describing the Z-80/6502 interface, or any protocol for invoking RWTS (or anything else) under the 6502. >Finally, it is possible to make BIOS calls through BDOS by >using function 50. (I think that is the right number). This >function was designed for this purpose. It will return to you >a pointer to your data in CPM memory where you can get to it. >It does all the bank switching and copying for you. It looks like this is what I need. Unfortunately, its calling sequence looks like one of the best kept secrets in the industry. Every document I've seen that mentions it simply states that DEreg passes a "BIOS PB [parameter block?] address" and that Areg returns with the "BIOS return." Nowhere have I seen the field offsets, sizes, and purposes of this BIOS PB thing; I am also curious about how the SELDISK BIOS call return value is passed back, as it's normally an address returned in HLreg. The BDOS function number for the direct BIOS calls is indeed 32H (or 50 in decimal). > Remember >though, interleave between CPM, DOS, and ProDos are all >different. (It's enough to make you scream!.) I've calculated the interleave translation, and I can even calculate it at runtime by reading track $11 (assuming the VTOC and directory are allocated the same way stock DOS 3.3 allocates them, probably a bad assumption but it works for me). As I mentioned in my previous posting, I have been able to coax the BIOS to read DOS sectors into shared memory, but this involved disassembling parts of the BIOS, and kludging in my own routines which switch banks and call the BIOS. The problems I've run into are that so far I've only been able to copy sectors into/out of shared memory, the subroutine I hooked into in the BIOS kept moving as newer BIOS revisions came out (not a flame, just an observation of a standard side-effect of software development), and the discovery that SID is loaded into the top of memory (into shared memory). The ideal solution to my problem, I believe, would be an implementation using the BDOS call we discussed. A second solution would be to find out where the BDOS keeps its transfer buffer in shared memory, and use my hack to switch banks and call the BIOS myself. I would appreciate any help that Gale (or anyone else knowledgeable about this BDOS call) could give me. Many thanks in advance, Paul Sander | Do YOU get nervous when a paul@athertn.Atherton.com | sys{op,adm,prg,engr} says {decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ? -- Paul Sander | Do YOU get nervous when a paul@athertn.Atherton.com | sys{op,adm,prg,engr} says {decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?