Author Topic: Z80 memory banking for 128K - MMU design  (Read 32832 times)

0 Members and 1 Guest are viewing this topic.

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #75 on: November 24, 2017, 12:53:50 am »

Can think of a couple of problems areas.

With the memory mode you are running the memory in, you need U8:A & U8:B wired like grant's drawing. Pins 3 & 6 connect to ram/rom grant's way.
Pin 3 to ram WR
pin 6 to RAM & ROM OE

All Ram/rom address/data lines go to Z80
Except for A14 and higher.

Did you get the High 16k area of ROM programmed properly?
It should match first 16K except for those bytes in the message.
If not sure
From What I know you were running 16K ROM with reaming RAM until all ram.
If so with only first 16K programmed you could strap A14,A15,A16 low only at ROM
Q4 would still do rom/ram but rom would act like a 16k rom

before step 4 I would

Patch/strap the 670 so it stays in tri-state output mode.
Remove connection to Pin 11Gr and pull high or strap high
does mot matter what Z80 does Q1-Q4 should remain high and connected memory pins high with ROM selected

If this is correct then output of 670 is probably correct.

If not and you have a second ROM, put 00h in all locations.
Z80 will do nop and A0-A13 of memory should count.

A volt meter is not a good way to troubleshoot a running computer.
job for scope.

Can I just stick a HALT at the start of MINIT: to do this? should work

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #76 on: November 24, 2017, 10:21:28 pm »
With the memory mode you are running the memory in, you need U8:A & U8:B wired like grant's drawing. Pins 3 & 6 connect to ram/rom grant's way.
Pin 3 to ram WR
pin 6 to RAM & ROM OE

Yep, that's all in place still.

All Ram/rom address/data lines go to Z80
Except for A14 and higher.

A14 & A15 from the Z80 go straight to the MMU (670).  The Z80's A14 & A15 are now only connected to the rest of the address bus via the MMU.

Did you get the High 16k area of ROM programmed properly?
It should match first 16K except for those bytes in the message.

Yes, I've actually copied the monitor code into all 8 banks of the ROM earlier this evening (00000h, 04000h, 08000h, 0C000h 10000h, 14000h, 18000h and 1C000h) - so whichever ROM bank is selected, the SBC should boot.  It still doesn't, so this tells me that the ROM isn't selected at all by the MMU (which backs up the multimeter reading I took yesterday on Q4 being low.)  When I get more than 5 minutes to work on the issue, I'll get the oscilloscope out so don't worry, I won't be using the multimeter anymore. ;)

So, I've had little time today to look at the issue but I was able to program the ROM with monitor code in each of its 8 banks and try the SBC again.  It still doesn't boot, so this backs up my earlier observation that Q4 was low and thus the MMU wasn't selecting the ROM properly for boot.  I'll take a closer look at the MMU this weekend and check the voltages and signals to the 670.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #77 on: November 25, 2017, 05:49:19 am »

My first thoughts on last post.
Use a 138 NOW to select the ROM & RAM chips.
So if you connect the address input of 138 to Q4 and can swap connections, could be a quick get computer working step with a better future.
This still has all RAM or ROM and needs 670 to add the other.

You only need one address input to select between the ROM & RAM chips.
And the BIG one, you can swap connections between Y0 & Y1.
AND Know that only one output will be enabled at a time.

Some day I am guessing that you will want to do something and need a memory space to do it in.
You will have two more address lines you can use for future memory expansion.
You will have three inputs you could use to disable memory in future. This is a powerful thing. Take a glance at Mouser 9 different parts you could use to make a 256 byte block of memory special from an additional memory chip and where in Z80 memory controlled by an output port (Logic Comparators 8bit Identity ).

But the really great thing you could directly connect 138 to Z80 for some tests if connection to Q4 fails.

So Test steps
Read complete post and change order for what you see happening.

Looking at Grant's basic code
Looks like it wants ram starting at 16k & has question for top of ram.

So quick question you might know, will it work with just 16k of ram?
Thinking of telling Basic that it has 16k of ram.

If you connect Z80 A14 to 138's address input you can have 16k rom & 16k ram.
You could disconnect Q1-Q4 from memory
With RAM & ROM your interrupt SIO could work.
Should be small change if it does not work.

You could use BASIC output port command to test some of 670 function.
Knowing that GR(pin 11) RA ( pin 5) & RB(pin 4 ) for 670 dip control what happens on Q1-Q4 and nothing else you could jumper these to what you want.
Use basic output port instruction to write to 670 and check Q1-Q4
You could also check the connection that should go to GR

The problems come with connecting 670 to memory.
IT is almost work or die.
If the copies of rom are the same then you could swap rom with out crash.
The question is then did it work?

The way to find this out is make each of the rom copies different in a way that does not crash the Z80.

You could make Power up prompt output the Bank value.
8 copies of your 16k rom with one byte changed.
How you connect output of 670 and the inputs listed above determines what you get.
With original connection of 670 inputs
  Area 0 could switch to even banks
  Area 1 change is a risk of crash
  Area 2 could switch to even banks
  Area 3 could switch to odd banks
  Area 0 & 2 would always be ROM but you can change bank.
  Area 1 & 3 would always be RAM.but not connected for change.
First connect Q1-Q3 only to ROM keeping the 138 connected via A14 to control RAM/ROM
Un-used address inputs to ram strapped to a level.
You could change area 0 & 2 via basic the then peek the changed byte.

When this is working you could add RAM to Q1-Q3
This is the big step. Change area 1 and expect a crash
 You can test area 3 changing ram bank
All software must be correct
You can not swap bank where program is running.
You can not swap bank where stack is located.
You can not swap a bank and mess up interrupts.

when you change connection of 138 from Z80 A14 to Q4
You have 0-7 = RAM, 8-F = ROM
Now you know that basic should not change ROM code.
Break the rule and swap area 0 with a copy of area 9
Use Z80 to copy ROM to a unused block of ram.
You can then swap area 0 with this ram block.
Remember to change that one byte when coping rom.
Check byte after swap.

Think of what you have tested
You have not changed Area 1 and above only works if it stays the same.
You have tested Area 0 of 670
You can test area 2 & 3

You used the Rom BASIC to make changes and test change worked.

Now think about using MMU
You could setup a new table for interrupts in a different area.
When you change the I register You just made new table active.
This could be only a table location change.
Any time you want you can change contents of interrupt table as long as you keep it pointing to good code.

You can move the stack to a new area. With good code you could move back to old stack at proper time if needed.

CP/M3 with proper code you write will do this changing for you.

Even with CP/M2 you can do huge programs & huge data.

Think about your scope or meter
Often you can use even when out of calibration.
You meter is a ratio device. The same scale is showing a ratio. You can use this to check if meter is working.
The scope uses voltage for one ratio and time for other ratio.
A lot of time when using a scope you just care about the shape.
You have things you know what they should be.
Instead of measuring everything compare things.
If you have a logic divider you know output should be about 1/2 input in time.

Think about your Z80, standard test conditions for CMOS version is 4.5v to 5.5v for supply.
Good TTL logic 0 is < 0.8v with a logic 1 > 2.4
Lots of things you can compare with scope.
Most of time you are looking for a difference from something that should be close to same.

USB power shows X, 74LS670 should be close to same
Z80 is close, other chips are close, you have why the difference for any half way working scope.
This works even with changing signals if you have something else to check for comparison.

Old analog volt meters would shake needle some on DC with low frequency noise. Digital gives a slow average.
Scope shows noise and lets you decide that is about correct DC level.
A bad diode or cap shows quickly on scope.
 

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #78 on: November 26, 2017, 12:33:06 pm »
Okay, spent about 15 minutes sanity-checking the wiring and found two howlers where I'd mis-connected a couple of address lines and for some reason had two select lines running from the 138 (one through the OR gate with ~WR and the other direct from ~Y7.)  :palm:

It's working beautifully now, even at 8MHz!!  :-+

I'm able to swap RAM and ROM banks in and out with ease (confirmed using my memory viewing program and writing the bank numbers to the start of the 16K block using POKEs) using the BANK command I created for the monitor (DMI) program - all I need to do now is tweak a couple of CP/M programs that handle returning to the DMI without doing a (very) hard reset (have to power the SBC off until I MMU-ify the appropriate CP/M program that returns me to the DMI) and create the BANK command for CP/M and I've got a 256K computer. :)

Thanks C and Ian.M especially for your assistance. Couldn't have done it without you!   :-+ (On to the PSG now!)
 
The following users thanked this post: Ian.M

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #79 on: November 26, 2017, 12:53:03 pm »

For Z80 you have a CALL instruction
Call instruction puts return address on stack
Sub uses RET instruction
return address gets used

MMU version

Z80 calls bank swap sub whth data, Data = address of sub or address of data

Bank swap sub
pushes return bank address info on stack
swaps the bank
calls the sub
Sub returns to bank swap sub
swaps back to original bank
returns to program.

For data  you need to move it both ways.
The Z80 has a PUSH instruction
You need bank PUSH

Z80 has a POP instruction
You need a bank POP

Keep in mind that sometime a word value or something else like a buffer will be split across two banks.

 
The following users thanked this post: nockieboy

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #80 on: November 26, 2017, 01:44:59 pm »
If you manage to add an extra FLASH chip for ROMdisk, get CP/M Plus running, loading from ROMdisk and layout a nice PCB for it you'll have a really nice 'retro' system.  Consider designing it as a S100 bus CPU card to make it easily expandable.  You'll need bus buffers and probably a programmable wait state generator for accessing S100 bus peripherals, and some of the memory space will need to be mappable to the bus, so you may need to add another '670 to gain some extra address lines EA18-EA21
« Last Edit: November 26, 2017, 01:50:02 pm by Ian.M »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #81 on: November 26, 2017, 02:14:10 pm »
Sorry I forgot the  :-+

Now before you get tooo distracted by other things.

Would be a good GREAT idea to look at your timing.

Is the Z80 working with low time margin when running a 8Mhx?

Could this margin be such that some instructions could be read from memory wrong?


lan.M
  I would not build to S100. Old bus with high dollar cards due to the hack on top of what was previous S100 standard.
Has a lot of good ideas that should be copied.

The Z80 will work on a VME bus. This is a large step up from S100. Built with idea of vector interrupts, many processors, large address space & 8 or 16 bit CPU's.
Should take less chips and just work better.

Would be a good idea to get out your scope and measure things.

For instruction fetch
Trigger on M1

Look at Z80 data sheet that lists times and measure them using your scope.
What you want to know is all at the Z80 chip pins.
For address bus you are looking for a range of when change starts and ends
A range for data bus.
here you have two ranges you can collect Rom/Ram Boot rom / CP/M

Get range of Q1-Q4 of 670

Get values at Rom Ram pins.

Get values for Z80 memory read/write

Get values for Z80 IO read/write.

If you think you have poor scope then record the time base setting.
Think you have an AVR with a crystal get it's time.
A 16mhz crystal should be close to 16mhz. This is a check on scope time base and could be a correction factor for an out of cal scope.

Last circuit I saw for PSC, could have data on bus for too long a time. Would be good to check.
It could be working, but not good long term to have two things driving a signal.



EDIT ADD

The MMU control is output only.
You will need MMU area values  when you try to get back from using or working with a different area.

Software FIX
You have a copy of what was last written to MMU in common memory.
When you start to make a change to a new bank,
  1. push a copy of common memory MMU values on to stack
  2. as you make changes to MMU change common memory MMU values also.
Use the new MMU map

   3. on return from using MMU map
Read old MMU values from stack and update MMU and common memory MMU values

This setup lets you change MMU many times and return back to previous settings.

This is foundation for what could look like magic.
« Last Edit: November 26, 2017, 05:26:56 pm by C »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #82 on: November 27, 2017, 12:05:17 pm »
EDIT ADD

The MMU control is output only.
You will need MMU area values  when you try to get back from using or working with a different area.

Software FIX
You have a copy of what was last written to MMU in common memory.
When you start to make a change to a new bank,
  1. push a copy of common memory MMU values on to stack
  2. as you make changes to MMU change common memory MMU values also.
Use the new MMU map

   3. on return from using MMU map
Read old MMU values from stack and update MMU and common memory MMU values

This setup lets you change MMU many times and return back to previous settings.

This is foundation for what could look like magic.

Already sorted that before the MMU was functional, C.  :-+  The command I used to change Area/Bank mapping will, if no parameters are passed, show you what the current mappings are:

Code: [Select]
OK
bank
Current memory mapping:

AREA 00 -> BANK 00 (RAM) *LOCKED
AREA 01 -> BANK 01 (RAM) *LOCKED
AREA 02 -> BANK 02 (RAM)
AREA 03 -> BANK 03 (RAM)

RAM: 64KB, ROM: 00KB
OK
bank 02,06
OK
bank 03,0b
OK
bank
Current memory mapping:

AREA 00 -> BANK 00 (RAM) *LOCKED
AREA 01 -> BANK 01 (RAM) *LOCKED
AREA 02 -> BANK 06 (RAM)
AREA 03 -> BANK 0B (ROM)

RAM: 48KB, ROM: 16KB
OK

EDIT:  In case you're wondering (you're probably not) - the *LOCKED comment means that Area is fixed and cannot be changed with the BANK command, so you can't inadvertently crash the system by swapping out the stack and currently-executing code.  Of course, there's nothing stopping you doing it with direct OUT commands, but it's an idiot filter for when I'm not thinking about what I'm doing.  ::)

Code: [Select]
bank 00,0f
Cannot remap locked Areas
OK
« Last Edit: November 27, 2017, 12:09:49 pm by nockieboy »
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #83 on: November 27, 2017, 03:45:23 pm »
Adding hardware read-back of the MMU registers could be done, but the logic cost of doing so is probably prohibitive in a LSI/MSI glue logic build.

Unfortunately the cost in logic to guard the MMU I/O port so it can only be accessed immediately after a specific instruction sequence is also prohibitive, so you'll have to be careful to avoid rogue programs that probe or scan ports etc. but its something that you should consider if you ever add a CPLD or FPGA that has access to the whole data bus, and the signals required to decode all memory and I/O accesses.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #84 on: November 27, 2017, 05:22:29 pm »

Think you are ready to work on CP/M3

For long term
  Think it would best to use CP/M3's relocating assembler.

If you were doing TurboDos I would suggest it's  relocating assembler.
 From memory the source changes were small to none.
Do not remember is source to both works.

There is also M80 that was from microsoft.

All three have linkers that let you put relocatable binary output together to make a working program
L80 is microsoft linker.

For text processing I used wordstar3.3

Some programs/code contained their own reallocators in memory.
The ones I remember used a simple bit table to change the value of a byte.

You assemble code two times with a ORG change of 100H
The binary bytes that are different are the bytes needing to change to move code in steps of 256 bytes.

From memory SID and ZSID did this.

Now that you have a MMU, what other areas do you want to learn?

I am assuming that you now know what would need to be changed if you wanted to use larger memory chips or a larger address space.
 
The following users thanked this post: nockieboy

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #85 on: November 27, 2017, 06:07:05 pm »
Also see https://www.z88dk.org/ for a relatively modern toolchain for Z80 cross-development in assembler and C.
 
The following users thanked this post: nockieboy

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #86 on: November 27, 2017, 06:16:24 pm »

CP/M3 & TurboDos both have a large amount of relocatable code modules that you use to build the system.

If you do not have new code in compatible relocatable code modules the build tools do not work.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #87 on: November 28, 2017, 04:12:47 pm »
Also see https://www.z88dk.org/ for a relatively modern toolchain for Z80 cross-development in assembler and C.

Thanks Ian - I'm already aware of the site as I found it in previous searches to do with building the SBC.  I haven't had the opportunity to take a long look at the site yet, but if it offers tools that will help with getting CP/M 3 up and running, I will certainly do so!  :-+

Think you are ready to work on CP/M3

For long term
  Think it would best to use CP/M3's relocating assembler.

Yes, I think that's going to be the next project - I'll leave the PSG until CP/M 3 is stable, as the majority of the work to do with getting the PSG running is software-based rather than hardware (although there's still the clock timing issue I have to resolve.)

Some programs/code contained their own reallocators in memory.
The ones I remember used a simple bit table to change the value of a byte.

You assemble code two times with a ORG change of 100H
The binary bytes that are different are the bytes needing to change to move code in steps of 256 bytes.

From memory SID and ZSID did this.

Now that you have a MMU, what other areas do you want to learn?

Well, I'd like to get CP/M 3 up and running!  ;D  Not sure where to start with it, really, as CP/M 2.2 was provided ready-configured on Grant Searle's website, so there was nothing I had to do to get it working from the start.  I've added a few tweaks to CBIOS since then, but nothing too complicated and only relating to varying the baud rate of the SIO depending on the system clock speed and getting the MMU up and running.

I'm going to have to sit down with the CP/M 3 System Guide I think and see what questions arise from reading that.

I am assuming that you now know what would need to be changed if you wanted to use larger memory chips or a larger address space.

I think so, yes.  If I start thinking about upgrading the physical memory space, I'll be sure to check in here first to check my designs out with you guys though. :)
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #88 on: November 28, 2017, 04:44:35 pm »
Take a Z80 emulator that supports banked memory and, ignoring any existing CP/M, port CP/M Plus to it.    Here's a configurable Z80 system emulator: https://k1.spdns.de/Develop/Projects/Z80%20EMUF/ that appears to be recently maintained, and from a quick skim it looks like you can code an exact emulation of your Z80 system using it.

If you want a more advanced MMU in the future, I'd suggest the one I initially pointed you to using '486 era cache RAM for the address translation.  These very fast small 5V SRAM chips are getting rarer and harder to find, so it would be worth acquiring a few sooner rather than later.
 
The following users thanked this post: nockieboy

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #89 on: November 28, 2017, 04:59:49 pm »

CP/M 3 is just an expanded CBIOS

Think that you will find that most grant's CBIOS will work for same CP/M3 CBIOS Function.

You are just adding some new functions fo most part.

There were some code cleanup's done.
From memory
CP/M2.2 CBIOS  had most sector blocking code in CBIOS, the putting/getting the 128 byte blocks ito/from to large block for drive.
CP/M3 now does more work making user created CBIOS simpler.

Just start with Grant's CBIOS for 2.2.
Check each function in Grants for a change on how it is called and what output is wanted.

Add the new function calls.
Think there are examples where you have dummy functions for CP/M3 running in 64k or less memory.

Do this step first. Result should be a CP/M2.2 program that changes OS from 2.2 to 3.0.
Should see little change, A CP/M2.2 program most times see no change. 
Disk format should not change.

Not worth time jumping to emulator where you have a working CP/M2.2 CBIOS to start from.
 
The following users thanked this post: nockieboy

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #90 on: November 28, 2017, 05:16:13 pm »
Jumping to emulation gives you debugging capabilities that aren't possible on a real Z80 system without FPGA assistance, .   I did a paper study way way back in the '80s before FPGAs and cheap MCUs were a thing of what it would take to build an invisible Z80 hardware debugger - no resources used on the target system, and CPU state restored as fully as possible on a normal Z80 chip before resuming execution,  and it was going to be a real bear to build and implement.   

Also, if you want to share your project, a working emulator will go a long way towards popularising it . . . . .
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #91 on: November 28, 2017, 06:14:37 pm »


Sorry lan.M

Did not say last very good
Depending on emulator capability nockieboy having access to one would be in good to great range.

For CP/M3
Here he states that he has software that he used to change the MMU and Check it's function.

Only step left is to make parts of this a CP/M3 function.
Do not think nockieboy will have much trouble with this step.

Remaining steps are also small
Most CBIOS functions will be un-changed.

Un-like CP/M2.2, CP/M3 is a CP/M2.2 program.

The old load cpm2.2 from boot track has changed to a loader that then loads the OS as a OS file and runs it.

You can have many different versions of CP/M3 on the boot disk and a change is just running a program.

Run program A to get CP/M3 for non-banked.
Run program B to get CP/M3 for banked.
A rename can change which starts at boot.

The capability to quickly build a new version is why you want to use CP/M3 tools.
A linker input change could be all that is needed to create the wanted version.
Modular Assembly code.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #92 on: December 04, 2017, 02:38:57 pm »
Okay, I'm going to just throw this out there with an acceptance that 'you told me so' previously....  ;)

Now that I'm working on getting CP/M 3 running on my SBC, I've realised that 128K SRAM isn't a whole lot - it only allows CP/M 3 to have a maximum of three banks effectively, if I allow 32KB for each bank rather than 48KB - and only two banks if I use 48KB each.

So I'm considering replacing my 128KB SRAM with a 512KB version.  This (with the 128KB EEPROM) would take the memory up to 640KB - and as someone once famously said, "640KB ought to be enough for anybody." :-DD

There's a big hurdle to jump first though - namely that my current 128KB SRAM is embedded amongst address and data wires on the breadboard.  So I might leave the physical upgrade until I get my SBC onto PCB.

But thinking ahead, I'll need to upgrade my current MMU to allow for another two address lines (EA18 & EA19.)  This can easily be done with the addition of another 74LS670 chip, but what would be the best way to wire it in to the existing MMU circuit?  I presume EA17, the existing ~RAM/ROM select line, would become the ~GR input for the second 670 and I'd remove the inverter to place it on EA19 coming out of the second 670 and going to ROM?
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #93 on: December 04, 2017, 03:39:10 pm »
Nope. 
Its read mode input connections (RA RB, /ER) go in parallel with the existing one, and its outputs Q1:Q4 become EA18:EA21 for a 4MB address space.

Then you have to sort out its write mode inputs so you can load a page table.
Currently you are using a one address write only port with two bits in the byte for '670 addressing.  The way forward is to move the existing and the new '670 write addressing (WA,WB) to Z80 A0,A1 and use four I/O addresses.  Then you can hook the new '670's D1:D4 to Z80 D4:D7, so the low nibble gets stored in the old '670 and the high nibble in the new '670.   You then have to sort out the BOOT mode disable signal - it was a port bit, but the easiest thing to do now would be to make any write to that port block leave BOOT mode.   The first value written would need to map the boot block at the current execution page so the bootup code doesn't crash.  Then you can map the other three pages as required, and finally transfer execution out of page 0 and remap page 0.    It wouldn't be possible to return to BOOT mode for a soft Reset, but you could fake it by mapping the boot block to all the pages and jumping to address 0.

It gets a lot easier to page efficiently if your MMU page size is a lot smaller (4KB seems optimum, giving a 1MB address map) and it can swap between preloaded page tables with a single OUT() instruction.   As I mentioned in your old topic, a 486 era fast cache SRAM  can be used to do that.  Up to 256 page tables could be preloaded, with separate entries for read and write mapping, which allows write protection, and also easy copying of ROM to RAM.  When you don't want that fine grained paging, simply create page tables that swap between 16K blocks.

I'd have to look at the details, but I believe that would permit a CP/M Plus or MPM system to have nearly 60K of TPA!
 

Offline glarsson

  • Frequent Contributor
  • **
  • Posts: 814
  • Country: se
Re: Z80 memory banking for 128K - MMU design
« Reply #94 on: December 04, 2017, 03:57:59 pm »
I'd have to look at the details, but I believe that would permit a CP/M Plus or MPM system to have nearly 60K of TPA!
You do not need a 4k page size to get 60k of TPA. My CP/M3 system I built in the early eighties used 32k page size with 62k TPA.
Never looked closer at MP/M, but I expect a small page size to be important when combining multiple users and large TPA.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #95 on: December 04, 2017, 07:21:44 pm »
Note first post had error in table below.

Quote
But thinking ahead, I'll need to upgrade my current MMU to allow for another two address lines (EA18 & EA19.)  This can easily be done with the addition of another 74LS670 chip, but what would be the best way to wire it in to the existing MMU circuit?  I presume EA17, the existing ~RAM/ROM select line, would become the ~GR input for the second 670 and I'd remove the inverter to place it on EA19 coming out of the second 670 and going to ROM?

Think of what you are saying here.
Existing MMU always has some memory enabled for a memory cycle. The CS enable is just by the address lines.
The current MMU is 4 16k areas of 256K
Using Q4 of 670#1 to control -GR of 670#2
670#1 16k area 0
670#1 16k area 1
670#1 16k area 2 670#2 16k area 2   <-( left this out on first post )
670#1 16k area 3 670#2 16k area 3

OR
670#1 16k area 0
670#1 16k area 1
670#1 16k area 2 670#2 16k area 2
670#1 16k area 3 670#2 16k area 3   <-( left this out on first post )

With extra I/O input to 670#2
670#2 16k area 0 could change to 670#2 16k area 2
or
670#2 16k area 1 could change to 670#2 16k area 3

I would say this is a big fail.

You only have two address inputs from Z80 to use to select expanded memory. Each bit added to output of MMU doubles the memory size you can select a 16k area from.

========
You always need to think of big picture.
Look at this from other way, not as how many banks CP/M can use but use of your memory.
With 16k banks, 4 are used by CP/M user program

So for big picture, your problem is lack of banks in expanded memory.
A second problem is no space to put more banks in Z80 memory.

First question should be how many areas of Z80 memory can CP/M manage.
Remember that CP/M can use two modes.
Z80 does the work or DMA does the work.
DMA here can be something you write and can use more memory areas then CP/M.

For just one area managed by CP/M
CP/M will move data to common memory and then change banks and move data from common memory to new area. 
DMA will be Move data at this address with a size of  in bank X to
Bank Y at this address.

Need to remember that data could be in two source banks or detestation banks.
CP/M can not force a program to put the Disk I/O block all in one memory area.

With 16k banks, CP/M should know that only three can be changed and still have a common memory ares.

A CP/M program works with blocks of 128 bytes or less
CP/M storage interface can have larger sizes of blocks.
CPM will try to have all of a data block fit in one swapped area.

So two main use cases
Move a small block of data to/from user space.
Move a larger block of data to/from storage.

A large block to/from user space becomes a small block move of many blocks.

Ok time to think ahead and also do what you want.

From CP/M view,
two areas allows direct copy between areas.
Larger areas could allow CP/M to manage a larger total address space.
Areas that are outside of CP/M managed area can be storage
managed by your programming.

So think about this
Adding second 670 can give 4096k total expanded memory.

More logic will be needed for a smaller block size when using the 670's





First step could be for your current memory to act like normal memory.
To do this put a 138 in place of inverter chip select.
Before MMU you just jumper-ed UN-Used address lines to a level.
You now have a memory chip that is half RAM and half ROM.
By using A 138 to decode chip select to memory chips you could have 7 ram & one ROM of same size.
Do not use messy logic to decode memory.

Use a 138 to decode memory for each size of memory!!

You need more address lines to address more memory. Best use of added 670 is to add address lines so that each 16k area is from a larger address space.


look at how you are building now.

Putting memory on breadboard takes a lot of space and a lot of wries that can get disconnected. Most of the wires are daisy chained.
1. Look at having many 32 pin dip sockets you can plug your memory into.
    For max flexibility only a few pins need to be special and not connected to daisy chain.
    You need a  0.05 bus off wires ( a ribbon cable is 0.05). Three ribbon cable connectors could hold two dip sockets. Look at this to get some ideas. And you can have two more dips on other side of ribbon cable.
 
   On a board with solder pads this is a four hole bridge of  wire, top dip, bottom dip, wire , then a space and again for other side of top dip..

« Last Edit: December 04, 2017, 09:07:56 pm by C »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #96 on: December 04, 2017, 09:11:19 pm »
CP/M PlusTM
(CP/M Version 3.0)
Operating System
System Guide
http://www.cpm.z80.de/manuals/cpm3-sys.pdf

Think the following is correct

On page 11 it states banked system A min of 2 and a max of 16 of what CP?M calls a bank

Looking at Figure 1-2 on page 5

If you had Bank 0 split at 32k
Lower part could switch between 16 32k areas (512k)
and you need 32k for upper half.
A 512k Ram chip would let you have 15 CP/M banks.

Matching your MMU
Upper half of 16k for bank 0
lower could be 16 48K blocks (768k)
A 512k Ram chip would let you have 10 48k CP/M Blanks
16k for common and 16K unused by CP/M
or
Above 15 CP/M banks and 32k common.

Note the max for CP/M
32k switch area is  512k + 32k common
48K switch area is 768K +16K common

Above these limits can be memory managed by your code.
It would be easy to have Ram or Rom disks in memory.

If you look at figure 1-7 page 10

That could be a ROM disk drive
Your Z80 power-up boot could exist above Track M

Think of how little you need to write code to do this.

To power-up boot Z80 you need top 16k as ROM for power-up boot code.
Current code is
copy "Cold Boot Loader" from CF card (disk drive)
So a switch from CF to Expanded memory ROM choice on CP/M boot.

To Treat Some ROM as a disk drive
Table for CP/M to know structure of drive.
Code for CP/M to use to read/write to drive.

As Disk drive CP/M has tools to write/read "Cold Boot Loader"
After formating can manage all remaining space.
Drive size = ROM size - 16k(power-up boot)


 
 
The following users thanked this post: Ian.M

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Z80 memory banking for 128K - MMU design
« Reply #97 on: December 04, 2017, 10:29:37 pm »
Quote from: page 11
A minimum of two and up to sixteen banks of memory with the top
4K-32K in common memory. Bank 1 must have contiguous memory
from address 0000H to the base of common memory.

If your MMU permits fast paging in 4K blocks, (giving an address space of  1MB), a 16 x 60KB CP/M bank system is possible using a total of 964KB of RAM.   That's two 512KB (4Mbit) RAM chips, leaving 60K unused.   Add a latched port bit somewhere to swap the top one with a 512KB FLASH chip, that is initially selected on Reset, and you can use it for the bootstrap and also as a ROMDISK. Obviously you need to double-buffer if you need to transfer data from FLASH into the top RAM chip, but that isn't too much of a PITA.   About 500KB should be fine for holding CP/M Plus System and Utilities.

If you hook up the /WR signal, you can also write to the FLASH, but I'd make that manually switchable to avoid rogue code smashing your bootstrap or system disk.  With an appropriate utility (to run from RAM), that would allow re-flashing your system in-situ. 

The quiescent current for two 4Mbit SRAMs is low enough that you could make them battery backed - with some logic to force Z80 /Reset low if the unregulated supply drops, that could give you a non-volatile RAM disk.   Generate a NMI instead of a Reset, and add a handler for it and you could do suspend/resume.
« Last Edit: December 04, 2017, 10:32:33 pm by Ian.M »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #98 on: December 05, 2017, 03:29:57 am »


If your MMU permits fast paging in 4K blocks, (giving an address space of  1MB), a 16 x 60KB CP/M bank system is possible using a total of 964KB of RAM.   That's two 512KB (4Mbit) RAM chips, leaving 60K unused.

With fast static cache ram you could do this for a MMU.

Not possible using two 670 chips with out a lot of logic
Simple is 4 16k banks for Z80 using one address space.
With 8 bit output from the two 670's you could have 4MB total expanded space.
Or waste some expanded address space and use some 670 bits for extra control.

    CP/M                           MMU           
Block   managed              block
size     memory space      size
32K          512K                  32K
48K          768K                   16k
56K           896K                    8k
60K           960K                    4k

Need to remember that the floppy disk drives that most systems has wore small by todays standards.

If there was a standard floppy disk for CP/M it was a
8" single side, single density, 128 byte sector, 26 sector per track ,77 track drive
This is about 250k when formated
Double density increased this to 500K
Dual side to about 1M

A lot of computers used 5 1/2" drives 100k, 200k, 400k

CP/M3 can speed up a CF drive some.
A fast drive for CP/M is a ram disk.

So a small MMU block size sounds great but gains less with each step smaller for CP/M.

Using parts of the 4M space for RAM/ROM disks us a gain.
Using some of the 4M space to access new hardware or other systems is a gain.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: Z80 memory banking for 128K - MMU design
« Reply #99 on: December 07, 2017, 08:04:47 am »
If you hook up the /WR signal, you can also write to the FLASH, but I'd make that manually switchable to avoid rogue code smashing your bootstrap or system disk.  With an appropriate utility (to run from RAM), that would allow re-flashing your system in-situ.

I think this has been mentioned before - either in this discussion or one of my other related posts - and probably by yourself Ian.M, so apologies if my memory is failing me.  Although my current system has the FLASH ROM sitting in a ZIF socket on the motherboard, it's not without its own fiddly complications as the ZIF doesn't always quite sit properly and has to be pushed down to re-seat it etc. after a number of programming cycles.

I have every intention of putting this SBC onto a PCB in due course - either stripboard or (if costs allow) something more permanent, like a professionally-manufactured PCB - and whilst I don't mind having a ZIF socket on the PCB, in-circuit programming of the ROM would be a very nice feature to have!   :-+

Is there much involved in doing it?  I'm guessing that a switch would control the ROM's ~WR, after putting the Z80 into tri-state with a ~BUSREQ (not necessarily in that order, of course - I have an Atmega328 on the board which could run this sequence) and allowing the 328 DMA access to the ROM?

I'll start researching this idea I think.  I'm up to my eyes in CP/M 3 BIOS at the moment, so a hardware challenge will be a welcome distraction!  :-+
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf