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? Bob Bell On Friday, January 2, 2015 12:22:19 AM UTC-5, Max Scane wrote: > > 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. > > Cheers! > > Max > > > > On Fri, Jan 2, 2015 at 2:05 PM, Bob Bell <[email protected] <javascript:>> > 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? >> >> >> >> Bob Bell >> >> >> >> >> >> *From:* [email protected] <javascript:> [mailto: >> [email protected] <javascript:>] >> *Sent:* Thursday, January 01, 2015 5:02 PM >> *To:* [email protected] <javascript:> >> *Subject:* Re: [N8VEM-S100:5950] Bank Select Logic >> >> >> >> Hi Bob -- >> >> You might be able to fake an MMU for the 64k address space of the Z80, >> and do bank select without jumping into the extended addresses of the S-100 >> bus. Take a look at the 74LS170 or the 74LS670. These are chips that look >> like four 4-bit registers. You could use one of them to address 16k or 32k >> chunks of a 128k x 8 SRAM or a 512 x 8 SRAM, and have them appear within >> the Z80's 64k. Just remember that both these chips are open collector, so >> you will need to put pull-ups on the Q outputs in order to see the bit >> patterns that you expect to see. >> >> I've often wondered about building an S-100 card with one of these chips >> onboard to provide an extended address space. Maybe use a 74LS682 (or >> similar) to decode the MS 6 bits for access to the registers of the >> LS[1,6]70, and have various parts of an SRAM chip much larger than the >> Z80's addressing capabilities show up in the "normal" Z80 address range? >> One of those 512 x 8 SRAM chips could supply sixteen (aha ... 4 bits!) 32k >> x 8 pages. You could move 32k pages in and out by writing to the registers >> in the LS[1,6]70? I'm no electronics whiz, but maybe somebody else could >> work out the details? >> >> But then you are in the realm of segmented architectures. Why not go >> with an 8x86 CPU, and give yourself headaches that way? >> >> Roger >> >> >> >> >> >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "N8VEM-S100" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "N8VEM-S100" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "N8VEM-S100" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
Z80Bank-SelectSketch.pdf
Description: Adobe PDF document
