Hi John. I went to the link that you provided below and the first thing I saw that gave me the willies was that the process requires an IDE hard disk based system. I have the N8VEM IDE/CF card for my computer. It’s built and works with the MyIDE program to read and write the CF card. However, I have not had the time to complete BIOS modifications to make it work in CPM2.2. So, what is the possibility you know of a similar guide for working up a CPM3 non-banked, then banked system in a floppy environment? My CCS 2422 disk controller lets me put nearly 600K on a SSDD 8” disk, so I typically have plenty of room for such projects.
Thanks for your help.
2 banks of 16K is fine, 32 K better. More than that if you have many drives.
No practical upper limit. The CPM Bios does not know/care RAM has switched
Most of the bank switching code actually does not have to be in the common area, but you MUST have the actual switching code in the common area. The CPM3 BIOS has most of this stuff documented in the listings. See for example:
From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of Bob Bell
I think I have figured out the very basics of the bank select logic I need to make two 64K boards work in a banked scheme that have nothing more in regards to memory management than 24-bit addressing. I have attached a PDF showing how I think this could work. The first diagram is showing, essentially, the Z80 CPU, the two 64K memory boards with A16-A23 capability, and then the rest is a macro of the MMU/Bank-Select Logic. The second diagram is a much simplified circuit showing how just a single bank-select bit would be implemented, good enough for two banks. This could easily be extrapolated out to use more than one Bank select bit from the Bank Select register and output more than just A16. And I am currently only using A14 and A15 to select 16K chunks, good enough to implement, as shown, a 48K / 16K split. However, I already anticipated, on the first diagram, the need for finer granularity and brought A12 and A13 in. Additional address lines below A12 could also be used. I think I saw somewhere that someone said CPM3 allows the common area to be changed in 256 byte increments. So, perhaps down to A8. The logic to implement this, at this point, is rather simple, so I expect I'll be able to check this out in the not too distant future. (But I have to bring up a CPM3 system first.) I envision it being easily implemented right on the memory board, and with any luck, using just one GAL. I also think this will work on boards with more than 64K, as long as they can be addressed properly by the upper address lines.
And now some new questions:
1. How many banks can CPM3 work with?
2. What is the practical number of banks most users have in their banked CPM3 system?
3. I assume the bank switching code is in the common memory area - can someone confirm this?
The size of common memory is dependent on your driver requirements (common vs banked), CP/M's requirements as well as the capability of the hardware.
For each disk added to the system a certain amount of common memory is required, along with the non-banked portion of BDOS and the BIOS.
From memory, gencpm allows you to specify the common base address on a 256 by page basis.
Depending on how your MMU/banking CCT and disk hardware works, you may need to buffer your disk data transfers in common memory which will also use up memory.
Realistically, I doubt you will be able to get much smaller than a 16KB common area so it is really dependent on hardware capability and driver complexity I think.
On Fri, Jan 2, 2015 at 2:05 PM, Bob Bell <bbe...@gmail.com> wrote:
Thanks for your thoughts, Roger. I’ll have to do some thinking on your ideas and see how this chip might be used in the ideas I am formulating.
BTW – the LS670 has Tri-State outputs, so no need to be concerned with pull-ups using this one.
Another question on this topic for those who have already implemented banked CPM3:
The 32K/32K and 48K/16K split has been mentioned several times. Obviously I would think the 48K/16K split would be best from the standpoint of the largest TPA.
But does this put any serious restrictions on the OS?
And is there any practicality to splitting it to say, 44K/20K if there are serious restrictions and more room is needed for the OS in the common area?
Or are odd-ball splits (i.e. not on major memory boundaries) not possible?
Hi Bob --