Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Determine size of TPA / Base of BDOS

  1. #11

    Default

    One additional note, if you are attempting to run an "RSX" on CP/M 2.2, and keep it resident, you will need to make alternate arrangements for warm boot - particularly the CCP. Typical CP/M 2.2 installations have a copy of CCP on the boot tracks (or other reserved location) that is already relocated to the expected address below the BDOS. If you add layers below the BDOS, that CCP will no longer run. What CP/NET did was to provide a new CCP as a PRL/SPR and the CP/NET warm boot loads and relocates the new CCP file.

  2. #12

    Default

    No, it's CP/M 2.2 - no RSXes.

    Looking at it, I can run the loader under ZSID, and all the load addresses get moved down. This means that ZSID is pulling the same stunt that I am, so my drivers get loaded below ZSID. I can debug the loader like this, but not the driver code itself. Once the loader returns to ZSID (or indeed, the CCP when run without ZSID) the machine warm boots. Under CCP, it does this at the next command (even a built-in like USER, which as far as I know does not entail accessing the disk drive).

    Obviously an error on my part!

  3. Default

    Quote Originally Posted by durgadas311 View Post
    We're a bit off-topic, but the RSX runs in the TPA (bank 1) and as such it can't really intercept calls made by the BDOS to the BIOS. It would have to be running in bank 0 to do that.
    If the base of common memory is low enough that there's room for the RSX to load that wouldn't be a problem either (though the programmer would obviously have to deal with the possibility that it's called when bank 0 is paged).

  4. #14

    Default

    Quote Originally Posted by durgadas311 View Post
    One additional note, if you are attempting to run an "RSX" on CP/M 2.2, and keep it resident, you will need to make alternate arrangements for warm boot - particularly the CCP. Typical CP/M 2.2 installations have a copy of CCP on the boot tracks (or other reserved location) that is already relocated to the expected address below the BDOS. If you add layers below the BDOS, that CCP will no longer run. What CP/NET did was to provide a new CCP as a PRL/SPR and the CP/NET warm boot loads and relocates the new CCP file.
    Oh, sorry, you already knew it's CP/M 2.2!

    I think I may have made a blunder. When I examined the Superbrain's CP/M implementation, it seemed to me that the BDOS starts at the top of the TPA, but that is not true is it? It's the CCP that lives there. So if I do not deduct the length of the CCP from my load address, I will trample it. Oh dear. I think I see the problem!

  5. #15

    Default

    Well, the CCP is expected to be transient in CP/M 2.2. The top of the TPA is the start of the BDOS, the address of the JMP at location 0005h. The CCP assumes everything between 0100h and it's start address is "fair game" for it to use, so if you are trying to install the CP/M 2.2. equivalent of an RSX, and you want it to stay resident, then you will need an alternate CCP and to handling loading of it in your RSX. Your RSX will need to load itself just below the BDOS, which means the normal Superbrain CCP cannot be used anymore (it is not relocated to the correct address). You might be able to use MOVCPM, if the Superbrain CP/M has that, to get a CCP image based on the size of the RSX, and then load that from your RSX during a "warm boot".

    Basically, to have some code stay resident and act like an extension of the BDOS, it will need to sit between the CCP and BDOS. The CCP will need to be relocated, one way or the other, such that it is ORGed to the new address (BDOS-RSX). If your RSX is intended to only run during a specific program run (i.e. is a one-shot), then you have to rig up something to load the RSX and the program "as a whole".

    Maybe I need more detail of what you're trying to do?

  6. Default

    It may be worth looking at the source of XSUB, which is more or less the CP/M 2 equivalent of the GET RSX in CP/M 3. It comes in two parts: XSUB0.ASM, which loads and relocates the resident portion, and XSUB1.ASM which implements the BDOS call trap.

  7. #17

    Default

    Interesting.. What I am trying to do is install a driver for an IDE interface, which JohnElliot might be familiar with as he advised me on writing the driver for the Amstrad PCW256.

    It's not intended to be a permanent installation - more a tech demo to see if I can access the IDE drive under Superbrain CP/M. I expect it to be lost at each warm boot. This would be easy if there was a Superbrain MOVCPM, but there isn't. There are quite a few BIOSes for it, with and without source code, but there are also some hidden calls for which there is no source at all. It's a mystery to me why Intertec published one with out the other.

    Ultimately I will have to put the work in to build out a full set of source which can be assembled with the IDE driver in situ. But for now I thought it'd be nice to have a play with a loader hack.

    So.. I think the loader is working fine, it is just putting the driver at the wrong location (trampling the CCP).

  8. #18

    Default

    And so, after much mucking around..

    https://www.youtube.com/playlist?lis...ygFQxfKM3o-x99

    The driver installs below the CCP and so is vulnerable to programs that use a lot of memory or execute warm boots (which reset the BIOS table). If the driver stops working after a program is run (like, say, PIP, which always exits with a warm boot) you have to reload it. If you were logged into an IDE drive at the time, you have to cold boot, then reload the driver. But that is OK as this is just a technical demonstration of the driver and uIDE device.

    I did experiment with revectoring the BIOS jump at 0005h so that it pointed to the start of the driver, which in turn jumps to the original BDOS vector. The purpose of this would have been to fool programs into not using any of the TPA that the driver or CCP is using. I couldn't get this to work properly.

    The other experiment I tried was to replace the warm boot JP instruction at 0000h with a RET in order to try to prevent warm boots (where programmers have lazily ended their programs with "JP 0000" to force a warm boot. This did work, but not with PIP (which got very confused) or MBASIC (which, on executing the SYSTEM command to return to the CCP, just returned to MBASIC without doing anything - probably because it is calling the code that implements SYSTEM and a RET at 0000h is making the SYSTEM subroutine do nothing).

    So, we have to view the demo as just that for now. I'll have to rewrite the entire BIOS and boot ROM if I want it to work properly... but now I know it will work eventually, plus it was fun to find out.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •