Image Map Image Map
Results 1 to 9 of 9

Thread: Why did Gary choose the banking method that he did?

  1. #1

    Default Why did Gary choose the banking method that he did?

    I've read some about the CP/M 3 banking choice and I am wondering why he went the way he did on it - mostly because he took advantage of the banking for the OS, but I think his approach was not strong from an application point of view. Perhaps this was just an extension from MP/M. Watching the Commander X16 video where he showed the basic area at 40K and then an 8K paging system is much more user friendly and I wondered why CP/M didn't do something similar. After a little thinking about it, it occurred to me that if you essentially built a CP/M 2.2 where the top 8K was for the BIOS/BDOS and so the FBASE was at 56K, then the TPA would have a solid 56K section (less the bottom 0x100) to work with. Then if you make the top 8K bank switchable, the program could have access to page blocks of data and then put back the original block when BDOS needed to be called.

    If CP/M needed more memory, perhaps it could even use the area below 0x100 to change the upper 8K page for more memory? Perhaps that wouldn't even be needed, could code executing a bank change in that bank be setup so that changed bank's next PC is what is intended to execute?

  2. #2

    Default

    CP/M 3 was intended to be a single-user single-tasking OS. So there is only one TPA. Note that the TPA is not limited by the common memory boundary, but by the size of the resident BIOS/BDOS. So even with a banked size of 48K you still can get a larger TPA. I have CP/M 3 running with a 59K TPA but a 48K bank size. Since CP/M is resident in high memory, I think it makes sense that the low memory is banked. MP/M memory is a bit different, as programs might not run at 0x0100. MP/M (as does CP/M 3) supports programs that are PRL files, and so can be relocated to any memory segment. CP/M 3 just always relocates PRLs to 0x0100.

    Also, CP/M 3 needed to support a wide range of banking hardware, and so a simple high common/low banked paradigm is more portable. And most systems in that era did not have sophisticated memory paging capabilities.

    I'm not sure I fully understand what you're proposing, but I'm not sure that the CP/M3 approach was inherently inferior.
    - Doug

  3. #3
    Join Date
    Jan 2014
    Location
    Western North Carolina, USA
    Posts
    1,208

    Default

    FWIW, the CPU280 banking, driven by the Z280 PMMU, allowed CP/M 3 to have a 62K TPA. Tilmann was looking to max out everything on that board, and he succeeded.
    --
    Thus spake Tandy Xenix System III version 3.2: "Bughlt: Sckmud Shut her down Scotty, she's sucking mud again!"

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,218
    Blog Entries
    18

    Default

    My experience is with MP/M, which enjoys(?) a similar banking scheme. However, the hardware that I used allowed mapping the 64K of the address space to anyplace in the 256K of physical memory in 1K chunks, even allowing the same physical page to be mapped into two different addresses. MP/M wasn't nearly so sophisticated as to allow using that to the best advantage. I think the CP/M 3/MP/M scheme was devised to allow the simplest possible bankswitching hardware to work.

    You work with what you've got.

  5. #5

    Default

    Quote Originally Posted by lowen View Post
    FWIW, the CPU280 banking, driven by the Z280 PMMU, allowed CP/M 3 to have a 62K TPA. Tilmann was looking to max out everything on that board, and he succeeded.
    A common misconception, but the banked memory size does NOT determine the TPA size. It is the resident OS size that determines the maximum banked size, and *IS* the TPA. Since RESBDOS is usually fixed size (unless you rewrote the BDOS source code), it is the RESBIOS size that influences how much TPA you get.

    RESBDOS3.SPR consumes 1.5K, so to get 62K TPA you'd have to minimize the resident BIOS portion down to 512 bytes. I suspect it did not support many/complex I/O devices and probably not (character) I/O redirection. Or else it imposed extra bank switching in the character I/O path. Still, an impressive TPA.
    - Doug

  6. #6

    Default

    It just seems like the CP/M 3 banking was designed to benefit the OS more than the application. Its goal was a maximum TPA, but we are talking about a number of K here when a better target might be to make an interface that makes it easy for a program to use banked memory. Did CP/M 3 programs use banking for more memory commonly? I keep going back to the idea that a separate section of bankable memory might have been more ideal. It could be that the lowest 56K is TPA and the highest 8K is CP/M, and the program can change out the top 8K bank to access more memory for data, or even that the lowest 48K is TPA, the next 8K is CP/M, and then next 8K is a totally unused by the OS and available at any time banking area. I don't love the way CP/M 3 banks out a partial cut of the TPA to another part of the TPA - it just seems crazy.

  7. #7

    Default

    Swapping out the resident part of CP/M is really not always possible. If your systems uses interrupts - especially for the system clock - you can't take an interrupt while the user has banked-out the interrupt code. There's just certain practical restrictions.

    Applications of that era were usually written to work on both CP/M 2.2 and CP/M3, and so could not depend on banked memory. They did use overlays to allow for larger programs, but the data either had to be kept in memory or else an elaborate swapping scheme was needed. This could be provided by memory page swapping on CP/M 3 if the application was written to use it, and the OS (BIOS) made certain that it kept track of the current user arrangement of pages in "bank 1" so that it would be properly restored after interrupts and BDOS calls. But, there was no platform-agnostic scheme devised to do this, probably because any such scheme would dictate the underlying hardware too much.

    Keep in mind that CP/M 3 was really the last improvement made to the CP/M-80 line, and that product was essentially end-of-life from then on.

    You could "reserve" any amount of memory/address space above the BIOS that you wanted, at the cost of TPA. But again, that depends on specific hardware capabilities that were not common back then. And any applications that used it were not going to be portable.

    I'm not sure what you mean by "partial cut of the TPA to another part of the TPA". The TPA might be split at the common page boundary, but since the program was not running when that bank switch occurred, it didn't matter.
    Last edited by durgadas311; September 15th, 2019 at 12:24 PM.
    - Doug

  8. #8

    Default

    Thanks Doug - that was exactly what I meant, that part of a program could be swapped out an in - I understand that it didn't matter as it was restored before use. I guess the short of it is that the idea was that a program didn't need more than TPA. I wish there would have been some sort of standardized way to allow for more.

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,218
    Blog Entries
    18

    Default

    In fact, a primitive virtual memory scheme was implemented by several products under CP/M, but almost always within some sort of framework. For example, JRT Pascal allows for very large programs (larger than 64K) and used the disk for swapping program segments.

    I've also seen designs where an external interrupt automatically swapped in a system page. The requirement, however, is that an interrupt service routine could not access user data (page might not be resident). DMA similarly had to make certain that the user data was available for the duration of the transfer or that user data was copied to a system buffer before or after a DMA transfer.

    I don't know what the multi-CPU systems (e.g. Molecular) did in the way of I/O or BDOS residents for each CPU.
    Last edited by Chuck(G); September 15th, 2019 at 01:40 PM.

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
  •