Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!tektronix!zeus!dadla!donk From: donk@dadla.TEK.COM (Donald C. Kirkpatrick;6291236;92-716;LP=A;60rC) Newsgroups: comp.os.cpm Subject: Re: Fail to install P2DOS on Apple Message-ID: <3433@zeus.TEK.COM> Date: 25 Apr 88 21:41:11 GMT References: <3414@zeus.TEK.COM> <2864@crash.cts.com> Sender: news@zeus.TEK.COM Reply-To: donk@dadla.UUCP (Donald C. Kirkpatrick) Organization: Tektronix, Inc., Beaverton, OR. Lines: 44 In article <2864@crash.cts.com> mwilson@crash.CTS.COM (Marc Wilson) writes: >In article <3414@zeus.TEK.COM> donk@dadla.UUCP (Donald C. Kirkpatrick) writes: >> >> I sure don't see anything real obvious. One trap I fell into is to try >> to use M80/L80 and not use the phase pseudo op. I don't think it is >> possible to build a hex file properly without the org/phase statements >> as described. Every attempt without using org/phase resulted in hundreds >> of zero-filled records where I wanted nothing at all. > > One possibility would be to tell L80 to make a hex file with an origin >at the location you need. It doesn't have to start at 0100H, you know. If anyone knows how to force M80/L80 to make a .hex file with an origin at a location other than 100H without zero-filling all the space between 100H and the requested origin, I sure would like to KNOW. I am aware of all the switches in both M80 and L80. I sure can't find the magic combination. Perhaps I have an incorrect use of one of the pseudo ops (ASEG, ORG and so on). Please include your pseudo ops in your answer. >> Let me offer a ray of hope. I am including a program that I almost >> included with the submital. It trys to load the image into memory >> starting at address 4000H. That starting address leaves room to load >> the image and execute DDT/ZSID so you never have to write a .com >> file to disk. All you have to do is load the image by running the >> program, run DDT to add the bdos image, then run the program again >> to write the image to disk. > > Why is something like this necessary? The image is up in memory, >*above* where DDT/SID/ZSID will load. SYSGEN will load below this. The image in memory that is to receive the new BDOS patch is the reserve track image from the boot floppy. This reserve track image contains more than just a copy of the operating system. There is also a cold start loader, perhaps a sign-on message, maybe even a default command to be executed the first time the CCP is given control. It is the reserve track image that must be patched and that presents a problem. CPM standards do not exist for the reserve track format. The best I can do is to provide a tool in the event the BDOS image is contiguous on the reserve track(s). I might note that it is even presumptuous to assume that I can read the reserve tracks using standard BDOS calls. Quite often the skew factor on the reserve tracks are different than the standard tracks to optimize warm boots. (That was my problem with the Northstar, for those of you who have been patiently following this discussion.) Don Kirkpatrick