Announcement

Collapse

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • JohnElliott
    replied
    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...)

    Leave a comment:


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

    cpm3.png

    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

    Leave a comment:


  • Ruud
    replied
    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 http://sims.durgadas.com/kaypro/kaypro84x.html 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!

    Leave a comment:


  • Ruud
    replied
    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:

    cpm2.png

    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.

    Leave a comment:


  • durgadas311
    replied
    "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, http://sims.durgadas.com/kaypro/ram256k.pdf, 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 http://sims.durgadas.com/kaypro/kaypro84x.html 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.

    Leave a comment:


  • Ruud
    replied
    Hallo Doug,

    You understood the schematic all right. The reason for choosing a 8KB bank size and not 4 KB as was possible, has to do with the number of OUT instructions that have to be performed. 8 KB means I only need seven.

    I never ever hear about "read bank" or "write bank". I'm 100% sure that the C128 and Bondwell 14 cannot do that and these are the only machines I'm familiar with.

    As an aside, I believe you could adapt the 74LS612 to support XMOVE by feeding /WR to one of the MA inputs, and programming the bank registers accordingly.
    First, I haven't heard of XMOVE or LDIR either but I guess what XMOVE does. I know what you mean but I cannot translate it into a schematic so quickly. But it led to my own solution of using two 74LS612s: one for reading, the other for writing. Simple IMHO

    One understanding I have of CP/M is that, except one or two files, it is completely machine independent. This means that handling XMOVE is done by the BIOS or one of these files (BDOS ?). So if you want to copy (parts of) on bank to another bank, IMHO it is just a matter of temporary popping up an 8 KB segment of the source bank into an 8 KB segment of the destination bank that is not targeted (yet). Not as fast as your RD/WR bank combination but it will work.

    It seems I have a LOT to learn but as long as it is fun, I don't mind

    Leave a comment:


  • durgadas311
    replied
    Just doing a little math, the standard DRI BNKBDOS3 takes up nearly 12K. It of course depends on the complexity and robustness of your BIOS, but a fairly-fully-function BIOS I use takes up 13K. So, bare minimum I'd need 25K in bank 0. I'd want to put some directory buffers there, and assuming all devices have 512B sectors, that's maybe 1K. With XMOVE you can put disk data buffers also in bank 0, so maybe another 1K+ (otherwise disk data buffers must be in common memory, reducing the TPA). It is common for people to store the CCP.COM in bank 0, which would be a little over 3K, although with fast flash-based disk it may not be as necessary to keep CCP.COM in memory, especially without XMOVE. I guess you could also put CCP.COM in a ROM bank.

    Anyway, it sounds like it could be tight, but seems like there should be space in 32K for CP/M 3. With the ROM copied into high memory, you've got a bit of a tap-dance to boot CP/M 3, but I'm sure there are ways around the complications. Typically, CPM3LDR runs at 0100H so you can go that route. You might also make CPM3LDR another bank of the ROM. But, the banked portions of CP/M 3 will be loading into the upper parts of the 32K, as well as the upper parts of the common area, so you've got to keep the loader code small, and carefully-placed. The potential for CPM3LDR to overwrite itself while loading BNKBDOS3 may be the biggest challenge.

    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? Either way you've got issues to work out when booting. Some platforms have/had a "write under ROM" feature so you could simply copy the ROM into RAM in-place. Of course, with FLASH/EEPROM it puts a kink in how you update the ROM in-system.

    Leave a comment:


  • durgadas311
    replied
    Yes, a schematic helps a lot.

    So, if I understand the intent of your design, you have a "bank" register where bits 0-3 select a 32K "bank", and bit 4 selects ROM ("0") or RAM ("1") in address range 0000-7FFF. Address range 8000-FFFF is intended to always select RAM address range 8000-FFFF. It would appear that you allow banked access to ROM as well as RAM, depending on D4, which I presume is to facilitate in-circuit flashing of the ROM as well as allowing access to all code in the ROM (provided the ROM code is organized into 32K banks).

    NOTE: I'm not sure if that RAM/ROM select circuit is correct, it might be reversed/inverted. You may want to double-check that.

    So, I think you can make this work for CP/M 3, you just have a somewhat-restricted bank size so the amount of code and buffers you can place in bank 0 is limited.

    One thing that I believe is very important for CP/M 3 is the ability to do bank-to-bank memory copy operations. This has an impact on the resident size of CP/M 3 plus speeds up use of additional banks (e.g. directory hash tables). For your design, you'd need another 4 "bank register" bits to select the "write bank" differently from the "read bank". And then you need circuitry to switch the bank select based on /RD vs /WR operations. For normal CP/M 3 bank select operations, both (RD and WR) bank select registers would have the same value. But for XMOVE operations you would set the RD bank different from the WR bank and perform an LDIR.

    One problem with making finer grained bank/page select, for example as with the 74LS612, is that it requires more I/O in order to do a bank select. Your (simpler) design requires only one OUT instruction to select the bank (two, if you support XMOVE). The 74LS612 requires many, potentially 15 depending on common memory size, OUT instructions in order to switch banks. As an aside, I believe you could adapt the 74LS612 to support XMOVE by feeding /WR to one of the MA inputs, and programming the bank registers accordingly.

    Another approach to memory mapping is something like what was done in the Z180 (as well as many other MMUs). You set a register that defines the common memory boundary, then each bank select is a single OUT instruction to set the base physical page used for the banked memory. This allows common memory to be any size you want. You could have two (RD and WR) bank base registers, to support XMOVE, as well.

    Leave a comment:


  • Ruud
    replied
    Maybe it helps if I give you the schematic of my design:

    cpm.png

    The 174 latch serves as Memory Management Unit (MMU) selecting chunks of 32KB of RAM or ROM for the first 32 KB of the address range. When the range 8000..0FFFFH is chosen, RAM is always selected and always the same RAM (common area). In this case the very first 32 KB of the 62816. After a reset the first 32 KB of the 29F040 is selected in visible in the range 0000..7FFFh. So the Z80 has ROM available to start up from. It is not that I need it, it is just available due to its design.
    After the ROM has copied what ever is needed from itself to the common area and the Z80 started to run from there, it is a matter of writing the correct value to the 174 latch to fill the first 32 KB of the range with RAM. Writing 41h to the 174 will select the second 32 KB block of the 62816. The 29F040 can serve as ROM drive. For example, writing 01h to the 174 will select the second 32 KB block of the EEPROM into the 0000..7FFFh range.

    So my choice for going for a 32 KB ROM is not that I need it so big but it fits in the whole design. But if there is something wrong in doing it in this way I would like to know, please.

    The remark on just having an 8 KB common area triggered me to create another design. Expanding the above design with extra MAxx address lines won't work so created one using a 74LS612 MMU, The MMU enables me to pick any chunk of 8 KB of RAM or ROM for any 8 KB in the range for the Z80. If anyone is interested, let me know.

    Leave a comment:


  • durgadas311
    replied
    Originally posted by DeltaDon View Post
    ...

    PS - I've used a 2732, in lieu of the 2716) in the past when testing my own changes to the D.P. provided monitor program (1.83) assembly code. I just have to be sure to write to the correct 2K or write it twice, once to each half of the larger EPROM so the hardware finds the code and runs it properly. (A 2732 being used as a 2716 in this case) As stated elsewhere a true 32K program would need to load at F000 and eats 4K of the the maximum 64K TPA.
    I took the "32K ROM" to mean a modern 32Kx8 EEPROM.

    Leave a comment:


  • DeltaDon
    replied
    I don't know if this will help or just add to your confusion, but the S100 site has the manual for the Delta Products (also XOR Science) Z80 CPU board and on page 12 of the manual there's a description on how this board loads upper memory with the boot EPROM 2716 (16/8 = 2K for memory mapping), which is what I think your 32K ROM (2732 = 32/8 =4K or FFFF-4K = F000) is doing too. ROM's are sized by bits not bytes. Yours it is trying to load at F000 is seems to be acting somewhat the same as how the Delta Products EPROM is used. Page 15 provides a list of jump locations for various BIOS routine usage and most likely yours follows the same for jump routines to be used by CP/M and user programs.

    See: http://s100computers.com/Hardware%20...U%20Manual.pdf

    PS - I've used a 2732, in lieu of the 2716) in the past when testing my own changes to the D.P. provided monitor program (1.83) assembly code. I just have to be sure to write to the correct 2K or write it twice, once to each half of the larger EPROM so the hardware finds the code and runs it properly. (A 2732 being used as a 2716 in this case) As stated elsewhere a true 32K program would need to load at F000 and eats 4K of the the maximum 64K TPA.

    Leave a comment:


  • durgadas311
    replied
    Ok, resetting.

    So, there are three basic types/styles of ROM used for CP/M machines:

    A) ROM that exists only on RESET/power-on and is mapped out once CP/M starts.
    B) ROM that is always mapped in, at high memory, and CP/M fits below it.
    C) ROM that is dynamically mapped in/out based on need, and CP/M is designed to work under those conditions.

    "C" is the most complicated, and even more-so when adding banked RAM for CP/M 3.

    I'm not sure if you are using a 32K ROM because that is convenient, or if you really need all (most) of the 32K. It is possible to, for example, map only 4K of the 32K ROM and thus not carve-out such a large chunk of the CPU address space.

    So, one decision that needs to be made is where the ROM will be "ORGed" - i.e. at what CPU address does it "operate". Since the ROM needs to get control when the CPU is RESET or powered-on, something needs to provide at least one executable (meaningful) instruction at location 0000H.

    Another consideration is that ROM code typically needs at least some RAM in order to operate, certainly it needs a stack. So, if using scheme B or C, that RAM needs to be protected from CP/M in some way. Typically, the RAM used for that is placed at high addresses, and CP/M is kept below that (CP/M expects to have continuous RAM from 0000H to the last byte in the BDOS).

    As an example, the Kaypro uses an 4K/8K ROM ORGed and mapped at 0000H. This ROM uses several pages of RAM at the top of the address range, in order to maintain context, etc. The Kaypro CP/M is always created as a "63K" version, to reserve that high memory. The CP/M BIOS then makes the proper preparations and maps the ROM back in to perform various I/O functions. When I implemented CP/M 3 on the Kaypro, I was just not interested in trying to make that work on top of banked RAM, so I re-implemented all the ROM routines in the BNKBIOS3 and reclaimed all of memory, and also avoid yet-another bank switch tap-dance, since CP/M 3 is already bank-switching between the TPA (1) and system (0) banks.

    So, probably the first decision/question is: what purpose will the ROM be serving once CP/M 3 is booted and running? I guess a related question is what will be in this 32K ROM? If you plan on having the "boot" image of CP/M 3 there, that affects a lot of the next decisions.

    Leave a comment:


  • Ruud
    replied
    Originally posted by durgadas311 View Post
    If I understand your design, you have a "ROM BIOS" that you copy into high RAM,
    Maybe I should ask my question in another way: the systems I know have 4 KB of ROM and 60 KB of RAM at startup. Would it be a problem if it is 32 KB ROM and 32 KB RAM?

    I'm not sure what you mean by "I didn't see any need for RAM between 4 and 32 KB".
    The System Guide only mentioned what the size of the common area should be at least, nothing about any RAM needed below it. 32 KB of RAM should be more than enough and then IMHO 32 KB of ROM should not be a problem. But I wanted some conformation, just in case I overlooked something.

    CP/M requires RAM from 0000H to the top of the BDOS (RESBDOS3). The BIOS, even if running in ROM, needs RAM as well - which has to be outside of the BDOS or TPA. So, if your ROM code is F000-FFFF, then you probably also need to reserve RAM somewhere for that code to use. Your top page of memory may need to be lower than "F0". I'm assuming you still have a RESBIOS3 (usually in the same SPR file as BNKBIOS3) that provides stubs to call into the "ROM BIOS".
    Consider me as a simple user so far. Everything you mentioned here above is more or less new to me. I know how to build an engine, now I have to find out how to fit it in the car. But for the moment I have to be sure that the dimensions of the engine are right.

    Thank you anyway for your help!

    Leave a comment:


  • durgadas311
    replied
    If I understand your design, you have a "ROM BIOS" that you copy into high RAM, and want to use that when running CP/M 3? In that case, you must make certain the GENCPM creates a CPM3.SYS that adjusts the "top page of memory" appropriately. You have to tell GENCPM to not touch anything where your ROM is copied. A normal "all RAM" system would set the top page at "00". If your "ROM BIOS" starts at F000H, you would set the top page to "F0".

    I'm not sure what you mean by "I didn't see any need for RAM between 4 and 32 KB". CP/M requires RAM from 0000H to the top of the BDOS (RESBDOS3). The BIOS, even if running in ROM, needs RAM as well - which has to be outside of the BDOS or TPA. So, if your ROM code is F000-FFFF, then you probably also need to reserve RAM somewhere for that code to use. Your top page of memory may need to be lower than "F0". I'm assuming you still have a RESBIOS3 (usually in the same SPR file as BNKBIOS3) that provides stubs to call into the "ROM BIOS".

    Leave a comment:


  • Ruud
    replied
    Another question: is there a max limit to the ROM size? At this moment the design is such that at start-up there is 32 KB of ROM and 32 KB of RAM. So far I didn't see anything that forbids this amount of ROM. What I read so far is that only a part of the ROM is copied to the common RAM and then the ROM is swapped with RAM. I studied the behavior of my Bondwell and mr. Thompson more or less confirms this behavior. So far I didn't see any need for RAM between 4 and 32 KB. A conformation would be appreciated. Thanks!

    Leave a comment:

Working...
X