Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.

Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.

Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.

Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.

Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.

Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.

Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.

New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.

Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Question about the RAM for CP/M 3

  • Filter
  • Time
  • Show
Clear All
new posts

    "LDIR" is the Z80 "block move" instruction, basically it copies the number of bytes in the BC register pair from the address in HL to the address in DE. It is the fastest way to copy a block of memory using software (a DMA controller could do that much faster).

    The XMOVE is a BIOS entry defined for banked CP/M 3 BIOSes, it sets up a cross-bank move operation. You should read the DRI CP/M 3 System manual carefully to fully understand what needs to be implemented. The XMOVE call simply tells the BIOS that the *next* call to MOVE should use the inter-bank data provided.

    The banked version of CP/M 3 (BNKBDOS3) determines whether XMOVE is supported, and will use that to move data to/from system buffers when needed. The existence of this features allows disk buffers to be in bank 0 instead of requiring them to be in common memory.

    Regarding the 74LS612, from what I see it is a DIP40 device. That takes up a lot of PCB real state, and using two of them takes up even more. I'm not sure what you space budget is, though. As you already mentioned, you are reducing the number of MMU registers you must update when switching banks, so not all 16 MMU registers are being used. It's a trade-off, but you may want to consider supporting XMOVE.

    Also, if you are not locked-in to using the 74LS612, I think you could use a different approach that takes less space on the PCB and requires fewer OUT instructions to change banks. While reading through the Z180 datasheets in order to understand it's MMU is probably a long detour, you could basically implement that using a 4-bit output port to select the common memory boundary (or you could hard-code it with dipswitches), then use a 4-bit comparator like the 74LS85 to see if CPU address bits A12-A15 indicate common or banked memory. Then you could use an 8-bit port, or two, to select the bank address. You could also use a fast adder to allow more flexible selection of the physical memory used for each bank, and less wasted memory.

    A very simple/crude example is here,, that I did back in 1986 for a Kaypro machine. Because I needed to support DRAM refresh, and only had 256K RAM, that schematic is not what you'd want to use but it might demonstrate the general idea. There's a little description of that circuit at under "Memory Modification". Note, that circuit would waste the "duplicate" common memory of each bank (extremely simplistic bank select), but using an adder to combine a base address would allow each bank to better utilize all of memory.
    - Doug


      Originally posted by durgadas311 View Post
      Just curious, is there any particular reason you are ORGing your entire "monitor" ROM to run in high memory? rather than just let it "naturally" run at 0000H and using a "boot loader" routine that you copy to high(er) memory?
      The original idea still is to mimic (more or less) the Bondwell and C128. They happen to have 4 KB of ROM and boot from an external device, floppy drives in both cases. I want to start with doing about the same although the drive won't be a FDD but a PC. So I don't expect my ROM to be about the same size, the design just happens to give me 32 KB instead. Later, when I know how things work, I'll see if I can use these 32 KB ROM as a boot device. And I'm also thinking about starting with CP/M 2.2 first to keep it more simple.

      But I gave it a good thought and I decided to go for the MMU design instead. Just because it is more flexible. Have a look at the schematic:


      As you see, just a few parts. The flip-flop made out of the two 3-input NAND gates makes sure that the MMU starts up in "Pass mode". If you want to know more, let me know. Just one thing: not a single bit of software has been written yet. I first have to revive all very old knowledge I have of CP/M, or better, what should come in the ROM and how should the first files look like.
      With kind regards / met vriendelijke groet, Ruud Baltissen


        Originally posted by durgadas311 View Post
        "LDIR" is the Z80 "block move" ....
        Thank you for the explanation.

        Regarding the 74LS612, from what I see it is a DIP40 device. That takes up a lot of PCB real state, and using two of them takes up even more. I'm not sure what you space budget is, though.
        I have no idea yet what the costs will be with the momentary design. So far I made everything on prototype board. But there must be a first for everything.

        but you may want to consider supporting XMOVE.
        IMHO it should be possible with even one MMU, so why not.

        There's a little description of that circuit at under "Memory Modification".
        I did the same trick for my Commodore 64 and 128. And I learned a very important lesson: don't design hardware if there is no software support for it. But reading your site I realize I never have thought about using the extra RAM in the C128 for CP/M !!! Stupid, stupid, stupid. My only excuse: I simply didn't know that it was possible at all to use it for CP/M at that time.

        And you have a very nice and interesting site!
        With kind regards / met vriendelijke groet, Ruud Baltissen


          Here is a dirty hack of the previous SCH, now having two MMUs:


          Main differences: the extra MMU of course and I had to add a 139 2-to-4 demultiplexer. The MAxx outputs are activated by the ME input. The idea is simple: one output is activated by the WR signal, the other by the RD signal. If you see any flaws, please shoot.

          This won't be the final version. The idea is to replace the two 139s and the NAND IC with one GAL. It seems a 16V8 will do but I'm only human and could have overlooked something.
          Attached Files
          Last edited by Ruud; June 1, 2020, 01:21 AM. Reason: Error in schematic
          With kind regards / met vriendelijke groet, Ruud Baltissen


            There are various ways to do bank-to-bank memory transfers (XMOVE / MOVE), depending on the system hardware. On the Amstrad PCW, for example, which has a 16k memory paging granularity and can map any 16k block into any of the four slots, the KL_MOVEMEM function is used. This maps the 'from' block at 4000h, the 'to' block at 8000h, copies up to 16k, and repeats until all bytes are copied. On the Spectrum +3, which doesn't have that degree of flexibility in its memory paging, bank-to-bank transfers are done using a 64-byte buffer in common memory (select source bank, copy to buffer, select destination bank, copy from buffer...)