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

0 Members and 1 Guest are viewing this topic.

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #25 on: November 12, 2017, 07:21:57 AM »
You are getting there keep up good work.

An MMU enables lining to CPU about where the memory data actually is.
Remember that it takes time to do this. Here the 153 is delaying address data from A15,A14 to EA15,EA14
The 153 must select the input pin and the data on that pin then needs to get to output of 153.

An example of this MMU in use.
Your 128k rom has 8 blocks of 16k.
One block needs to be the Z80 power up boot code.
This boot code could ask you to pick 1 thing from the 7 other blocks.
Block 1   your system monitor program
Block 2  Grant's basic
block 3   microsoft's basic
...
Block 7 something.
All these different programs could be assembled to ORG 0H
The power up boot code when it gets an answer,
Sets area 0 to the proper block
jumps to address 0H
If you selected 1 then you are running the monitor.
selecting 2 gives you grant's basic.

This is just very simple use of this MMU.

=====

As  Ian.M pointed out and in my posts above

The Area bits should be together in one 273.
Each 273 will hold two areas.
So two bits of 273 area go to one 153 and the other two go to other 153.

The data stored in the 273 for an area is EA17-EA14 used to address memory.
The Switches (the 153) selects 1 of 4 sets of data based on Z80 A15-A14.
So if both Z80 A15,A14 are low, The switches select area 0 data The expanded address EA17-EA14 which then goes to your memory chips.

Your two 273 chips make up a 2 x 8 bit memory chip.
The Reset/clear inputs lets you force contents of the 2 x 8 memory chip to all 0.
Being able to set memory data to 0 like this is not normal for memory. You Ram memory chip when power is connected will have random data.

Now the 153 switches is using this 2 x 8 memory as if it is a 4 x 4 memory chip.

Think of your current ram chip
It has one set of data pins. You use these pins for both read & write.
The two 273's is like a  2 x 8 memory chip. It has data pins for Write & a set of data pins for read.
The 273 based memory has a data port for write and a data port for read.

You are using a 1 of 4 switch on the output of the 273 memory.
Your current ram chip has a built in 1 of 128k switch to select data.
A normal memory chip stores data, your 273's stores data.
A normal memory chip has a data selector,  the 153's are data selectors.
A normal memory chip has no reset input, the 273's does.
Most normal memory chips have one data port, the 273's + 153's have two data ports.

Now look at the 74LS670.
It is a 4 X 4 memory chip.
It has a data & address port for writing data.
it has a data & address port for reading data.
It has NO reset input.
It has a tri-state output for read data port.

This chip does all most the same thing as the two 273's & two 153's
Would use 4 outputs addresses of 4 bits.
It is a RAM memory, So you have random un-known data in the 74LS670 at power up.
To get valid data on output pins at power up,
You connect pull-up resistors to the Read data port that is connected to memory, when you enable tri-state mode the resistors will supply a 1 to memory address line.
When the 74LS670 read port is tr-stated your ram and rom chips will see an address of EA17-EA14 all being 1.
By tri-stating read port at power up, The Z80 when reset will ask for address 0h, The memory will respond with data fromEA17-EA14 = 1 + Z80 A13-A0 = 0.
The Z80 is reading the top 16k of memory but thinks it is the first 16k of Z80 memory.

Your Z80 boot program is running and can now put initial data into the 74LS670. When that is done the Z80 can then turn-off the 74LS670 tri-state and start using the data in the 74LS670 for  EA17-EA14.

So
An MMU is put between the CPU & Memory.
It allows lining to CPU about where the memory data is in the actual memory.
The CPU has a way to change the LIE

The computer you are using to look at this will probably have an MMU.
The OS can use the MMU to keep one user of program from messing with another user or program.
If a user or program can not access something then it can NOT make changes.
A computer can run more programs or data then will fit in memory, if it can store the memory contents for a while in mass storage, This is called Virtual memory.

Your mmu is using 16k blocks & has 4 areas.
Some systems use much smaller area blocks. One system I worked with used 512 byte blocks.
To change your MMU you may need to change 4 sets of 4 bits.
Using the same total memory(256k) and same 64k CPU memory the MMU using 512bytes could need to change 128 sets of 10 bits.

If you changed the MMU to use 4 sets of 8 bits then the total memory would increase to 4m.
This would be two sets of 4 chips or 2 74LS670's

Keep in mind what you might want to do in the future.
The 512k dip memory I found was in a 32 pin package.
The Z80 being able to access a lot of memory space is a powerful thing.
Memory does not have to be memory.
Some CPU's have I/O in memory space.
The extra memory space could be connected to other processors.

 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #26 on: November 12, 2017, 08:23:19 AM »

Little steps trying to use what you know.

You are using grant's logic to do Ram/Rom

Remove some of this and use a 273

U7 C & D is a FF
A 273 is 8 FF with a reset/clear input

To use a 273 you need a signal to drive the clock input.
You want to clock this input with a Z80 out instruction.
You need IORQ & WR & a valid write address.

With IORQ connected to U5 you have part of this.
You can use an additional 138 or 139 to get what is missing.
Lets use a 138 as it is easer to understand.

The 138 has three enable inputs.
One needs to be connected to U5
One needs to be connected to WR
A0 connects to A input
A1 to B input
A2 to C input
You how have 8 outputs that are Z80 I/O write to a address.
You can connect up to 8 273's
You can connect other types of chips to these outputs.
So you can connect one 273 and get the reset on power up of grants logic needs by using one output of the 273.
A zero on output of 273 needs to select ROM.

To get the 74LS670 to work
You need one output from the 273 connected so that a 0 makes the 74LS670 output goes tri-state.
OR
  You keep using grant's logic and have ROMDisabled connected to 74LS670 tri-state input pin 11.

Wa & Wb connect to Z80 A0 & A1

Gw ineeds to be Z80 out for a range of 4 addresses.
U5 is I/O for a range of 8. Need to add WR to this
With a 138 you would not connect A0 & A1 so that each output of 138 gives a 4 address ramge.


With 139 you only have one enable.
Connect WR to one half's enable.
Need to use one of the address input pins to connect to U5.
By connecting A0 to other address input pin
You get Y0 and Y1 as a valid Z80 output select.
Y2 & Y3 are no connects.
You can connect two 273's to the valid outputs.
When connected to U6
even address writes to 1 273, Odd address writes to other 273


for 74LS670 with 139
You connect A2 to address input
You get four outputs that are a range of 4 output addresses.

The 139 is dual so you could wire it up and connect
Two 273's
&
 Up to Four things that need a 4 address range like the 74LS670
You would need different outputs of U5 for each 139 half

With this you can co I/O write to 4 chip MMU or 74LS670 based MMU

 No other logic is needed for 4 chip MMU or 74LS670


Note my quick look at data sheets for 74HC670 & 74LS670 suggests you want the 74LS670 for the speed.

Parts count

4 chip MMU
1 138 or 139
2 273
2 153

74LS670 MMU
1 139
1 273
1 or more 74LS670
Pull-UP resistors for outputs of 74LS670's
A resistor back would work great.

 



 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #27 on: November 12, 2017, 08:39:22 AM »
Okay, preliminary schematic for an MMU using the 670 chip:



I'm a bit lost with this one - one minute I'm getting my head around using 273's and 253's, now I'm looking at a 670 and wondering how I connect it up...  :o :-//

Okay, so I know I have to add pull-up / pull-down resistors as appropriate to set initial startup values when the 670 is tri-stated during power-up - I need the bottom 16K of the ROM to be available to the Z80 in the bottom 16K of memory space on startup (0000h-3FFFh) - so I have a couple of questions regarding this circuit:

1) How do I finish connecting it up to the address bus / control line/s.  Do A14/A15 go to both the read and write address inputs on the 670?

2) I assume the IO select lines go to ~WE and ~RE?

3) Have I connected up the Qn outputs correctly to the address lines on the RAM/ROM?

4) The pull-up/pull-down resistors go in the data lines (D1-D4)?

5) Where does the flip-flop go?

You are getting there keep up good work.

Thanks C - though it's causing me some headaches now!  |O

Now look at the 74LS670.
It is a 4 X 4 memory chip.
It has a data & address port for writing data.
it has a data & address port for reading data.
It has NO reset input.
It has a tri-state output for read data port.

This chip does all most the same thing as the two 273's & two 153's

Yes and because of that (and my keep-it-simple mantra) I think I'm going to develop the 670 idea from here.  I just have a really poor understanding of how it works (or how to get it to work.)

To get valid data on output pins at power up,
You connect pull-up resistors to the Read data port that is connected to memory, when you enable tri-state mode the resistors will supply a 1 to memory address line.

Erm.. where?  Are you talking about D1-D3 on the schematic?

If you changed the MMU to use 4 sets of 8 bits then the total memory would increase to 4m.
This would be two sets of 4 chips or 2 74LS670's

Keep in mind what you might want to do in the future.
The 512k dip memory I found was in a 32 pin package.
The Z80 being able to access a lot of memory space is a powerful thing.
Memory does not have to be memory.
Some CPU's have I/O in memory space.
The extra memory space could be connected to other processors.

At the moment I'll be ecstatic if I can just get an MMU working with the 128KB I've got in the SRAM and ROM!  I'm not likely to want to expand the memory further - at least not for the foreseeable future and if I do, I can presumably add another 670 without major upheaval.

I understand the concept of an MMU, the difference between memory space and physical memory etc, I'm just struggling at the moment with the specific technical details of how the 670 works to give the Z80 extra address lines.  Ian.M mentioned the 670 would also require a flip-flop - I do have a 74HCT74, would that be suitable?  Where and how would I need to wire it into the MMU circuit above?

Sorry about all the questions - I'm happy to work my way towards designing this MMU myself, but my understanding of the chips we're talking about (and some of the concepts) is virtually non-existent.  ???
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #28 on: November 12, 2017, 09:42:40 AM »
Now connect  RA0 to Z80 A14 and RA1 to A15.  Connect WA0 to Z80 D4 and WA1 to D5.   Connect /RE to flipflop Q, flipflop D to D7 and flipflop /SET to Z80 /Reset.   Drive '670 /WE and flipflop CLK in parallel from your port address decode logic which should include Z80 /WR.

Now what happens depends on the byte you write to the single control port:

 B7  B6 B5  B4   B3   B2   B1   B0

Boot -- S15 S14 EA17 EA16 EA15 EA14


The MMU effectively matches S14-S15 against Z80 A14-A15 to give you four pages (each a 16K block of Z80 address space). Your ROM extends from EAddr 0x00000 to 0x1FFFF, and RAM from 0X20000 to 0x3FFFF.  You can map any of the four pages to any bank (16K block of RAM or ROM), so to set up a usable memory map, in BOOT mode, with the '690 outputs disabled and EA17-EA14 set by the pullups/pulldowns:
Code: [Select]
   LD B, high(PORT) ; assuming full IO address decoding
   LD C, low(PORT)
   LD A, $80 ; High bit set to stay in BOOT mode
   OUT (C),A ; set page 0 to bank 0 - the first 16K block of ROM.
   LD A, $99
   OUT (C),A ; set  page 1 to bank 9 - the second 16K block of RAM
   LD A, $AA
   OUT (C),A ; set  page 2 to bank 10 - the third 16K block of RAM
   LD A, $3B ; High bit clear to leave BOOT mode
   OUT (C),A ; set  page 3 to bank 11 - the fourth 16K block of RAM
Once execution is transferred to RAM,  you can remap page 0 to RAM as well. Because you want to keep the '690 enabled keep bit 7 clear:
Code: [Select]
   LD B, high(PORT) ; assuming full IO address decoding
   LD C, low(PORT)
   LD A, $08
   OUT (C),A ; set page 0 to bank 8 - the first 16K block of  RAM
« Last Edit: November 12, 2017, 09:46:46 AM by Ian.M »
 
The following users thanked this post: nockieboy

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #29 on: November 12, 2017, 10:08:33 AM »
First a good rule for TTL logic
TTL uses higher current to make a logic 0 then logic 1
Good idea to use Pull-Up resistors for TTL
Using Pull-UP resistors requires boot rom code to be at highest address block.

ian.M is putting all MMU control on one I/O output port.
Saves I/O ports at some possible cost of slower software to control MMU

My setup uses 4 I/O output ports for 74LS670 and one output port for boot.
One for Boot where only 1 bit is used leaving you 7 bits you can use.
4 addresses that you only write B3 to B0 from
 B7  B6 B5  B4   B3   B2   B1   B0
  X     X  X    X  EA17 EA16 EA15 EA14

If you add one more 74LS670 to get 4M range this becomes
B7      B6      B5      B4       B3      B2      B1      B0
EA21  EA20  EA19  EA18  EA17  EA16  EA15  EA14

With pull up resistors connected to outputs of 74LS670, just put the power up boot program in the highest 16k block of ram and have ram at top of memory.
When you disconnect A14 & A15
0000h-3FFFh the Z80 is asking for becomes
??00 0000 & ??11 1111 for high byte of address
The 74LS670 4 outputs are pulled to 1
1111 from 74ls670 and 00 0000 from Z80 to
1111 from 74ls670 and 11 1111 from Z80
This gives
3C000-3FFF range in expanded memory the highest 16 k block

You need the Z80 to see 0-16k as boot program. with the outputs of 74LS670 this is the high 16k of memory.

1.  A14/A15 go to the read data port address lines Ra & Rb

2. A0 A1 go to Wa Wb with the D1-D4 connected to Z80 data lines
   Gw is connected to Z80 output write for a range of 4 addresses.

3. Yes these are the highest address lines for ROM/RAM.

4. Pull-UP connect to Qn

5.  Read my last post. Rom disable for grant's logic or bit of a 273

6.  Grants logic is a FF,   one bit of 273 is a FF

Keep in mind that both circuits do the same thing with minor changes.
Tried to step you through the 4 chip logic
You understand the 4 chip version then you are very close to the 74LS670

Quote
Erm.. where?  Are you talking about D1-D3 on the schematic?
on 74LS670 pin GR(11) controls the tri-state of Qn outputs.

 74LS670
Think you understand your current ram chip.
You could think of the 74ls670 as two ram chips.
One ram chip is write only.
One chip is read only.
When you use write only chip to write a location say address 1 you can only read the data using the read only chip using address 1
The 74LS670 is like two ram chips but with only one storage location inside for an address.

Think you want to play and learn hardware using Z80
Z80 is also not bad learning software on.

For software side you can get more done using nice powerful tools.
For hardware side good hardware design is what makes it easer.

Grant's just a working computer with few chips. not a great hardware design.
Parts of design is for other microprocessers, still works with Z80 just not great.

MMU
   simple concept
      A circuit that lies about the address it uses.
      Here the MMU only stores address data used for the Lie.
      It can an often does store other data like.
        is this area accessable
        is this area writable.
        has this area been changed

The CPU asks for something by address.
   the MMU uses this address to access it memory. from this memory it gets the actual address to use with memory
  This takes time but can make a computer very powerful.
Even at the cost on having to add wait states for memory.

Think of what CP/M3  can try to do.
   that old slow floppy disk drive that is using 1024 byte sectors.
   CP/M programs want a 128 byte sector.
CP/M can read that 1024 byte sector from that slow floppy and put data in extra memory
Keep track of what changed and then write back to floppy if needed.
Many many things possible with more memory




 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #30 on: November 12, 2017, 10:44:30 AM »
Personally, I wouldn't use two '690 chips to map 4MB down to 64KB.   The benefit of the '690 is it allows a very simple MMU to be built to map 256KB down to 64KB in 16K pages. However its relatively slow so if you want to clock a modern Z80 clone as fast as possible it isn't a great choice.

I cant conceive of needing more than 1MB address space for a Z80 system
In the topic I linked to in the O.P.s earlier Z80 thread,  I contributed the concept of using a '486 era fast cache SRAM to do the mapping.  The spec was to map 1MB into the Z80 64KB in 4KB blocks.  Propagation delay was solely dependent on the SRAM used, possibly as low as 10ns. 

The smaller block size is far more versatile, and specifically makes it easier to work on large data sets, or implement a fast ROMDISK and RAMDISK, without any speed penalty, as the design could store 256 maps and, once a mapping was set up, you could select it or flip to another mapping with a single OUT instruction.  It mapped reads and writes separately for ease of copying ROM to RAM, and also to permit write protection of RAM.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #31 on: November 12, 2017, 01:27:01 PM »

nockieboy is trying to understand a MMU

I started with 4 simple chips
The storage chip(273) have a reset or clear input.
As reset/clear causes data to be 0, ROM is first and boot rom code is at 0-16k
Ram starts at 128k

The change from this to using an 74LS670 is
Using 4 I/O output addresses in place of two.
And a change from having a reset/clear input to using pull-ups and tri-state disabled outputs.
Disabled outputs with pull-ups causes output bits = 1
This change causes the boot rom to be at the highest block in memory.

The addition of a second 74LS670 becomes a simple step then when using 4 I/O output ports.
The benefit is a 4M address space when using 16k blocks, an upgrade from 256k
This shows that a few added bits can make a huge change in expended memory.

The logic of how these steps work is an important part to understanding an MMU.


nockieboy
  Grab a some paper and then work through this post

http://www.eevblog.com/forum/projects/z80-memory-banking-for-128k-mmu-design/msg1345498/#msg1345498
The drawing you create should be a big help in understanding both the 4 chip MMU and the 74ls670 version.
Think it will help a lot.

Next look at datasheet for 74LS670
http://www.ti.com/lit/ds/sdls193/sdls193.pdf
At top of page two is a logic drawing
Lets fix that drawing so that it makes sense as used in a MMU

Ra & Rb put these on right side inline with Wa & Wb
Gr put on   right side inline with Gw

You now have two address pins at top
a Ck input on left & a tri-state enable on right
Data pins at bottom.

Left side of chip is now Z80 I/O write inputs
Dn = data Z80 Data  D3-D0
W? = Address  A1,A0
Gw = Ck for write and =  Address + IORQ + WR

these pins are connected as a z80 output,
four i/o output addresses used
Data written is high expanded address to be used for the four 16k blocks
This data will become EA17,EA16,EA15,EA14


Right side is now MMU pins
Qn is expanded address to memory.   EA17,EA16,EA15,EA14
Rn is high address from Z80   A15, A14
Gr is output enable active low. When high Qn are in tri-state mode.


How it works
Z80 starts a memory cycle
Z80 puts address on address buss
This causes Rn to select 1 of the four data stores( the 16k area)
The data in store appears on Qn, this data is used as high part of expanded address.

How Z80 controls
The Z80 writes 4 bits of data into one of the four output addresses( an area)
The four addresses are area0 to area3

On power up
   Garbage is in storage.
   On power-up,  Qn is disabled by using Gr input,  A high level.
   With no output on Qn, pull-up resisters makes these pins = 1.
Write good data
   enable Qn output so data can be used, A low level on Gr.
     

On power-up with Qn disabled( and resistors pulling high each pin, each area is accessing

From
MMU      Z80                        MMU         Z80
0b1111  00000000000000  to 0b1111     11111111111111 a 16k area

The expanded address range of 0x3C000 to 0x3FFFF

with output disabled it is same as if Z80 wrote F in each of 4 locations

0-7 = Ram blocks
8-F = Rom blocks
Block F = Boot ROM code The highest 16k block.

The 4 chip version of MMU has
0-7 = Rom blocks
8-F = Ram blocks
Block 0 = Boot ROM code The lowest 16k block.

 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #32 on: November 12, 2017, 10:57:37 PM »
I cant conceive of needing more than 1MB address space for a Z80 system
In the topic I linked to in the O.P.s earlier Z80 thread,  I contributed the concept of using a '486 era fast cache SRAM to do the mapping.  The spec was to map 1MB into the Z80 64KB in 4KB blocks.  Propagation delay was solely dependent on the SRAM used, possibly as low as 10ns. 

Crikey, I'd forgotten all about that thread! That was a long time ago.. (well, it feels like it!)  :o

Okay, I think I'm making progress with this 2-chip MMU design, following Ian.M's suggestions so far:



I have really only two questions regarding this circuit now:

1) Where do those pull-up/downs go to select ROM bank 0 (lowest 16K in ROM) for Area 0 (lowest 16K in memory space) and RAM bank 1 (16-32K in RAM) for Area 1 (16-32K in memory space) on power-up?? (That's the minimum requirement to get the monitor running - once running, it can set up the memory as it likes.)

2) Ian.M - you state:

Drive '670 /WE and flipflop CLK in parallel from your port address decode logic which should include Z80 /WR.

My IO port address decode logic currently looks like this:



So I'm going to have to AND the Z80's ~WR line with the appropriate IO address select line from the 138 before it goes to the 670 ~WE and 7474 CLK?

Also, on a tangent, I think I'm going to have to add another 138 to decode some more addresses - I'm running low on IO lines! (only 2 left..)  :o  Although this MMU design would free up the IO line used currently to switch the ROM out in Grant's design...

nockieboy
  Grab a some paper and then work through this post

http://www.eevblog.com/forum/projects/z80-memory-banking-for-128k-mmu-design/msg1345498/#msg1345498
The drawing you create should be a big help in understanding both the 4 chip MMU and the 74ls670 version.
Think it will help a lot.

I got this, I'll break the crayons out and be right back...  ;D  The honest problem is I don't have 15 minutes to sit and focus on this at the moment (and it requires a LOT of focus due to my limited understanding) - I'm hoping to get some time during the week to work on getting my head around how to get the 670 doing what I want it to.
 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #33 on: November 12, 2017, 11:07:48 PM »
To get the 74LS670 to work
You need one output from the 273 connected so that a 0 makes the 74LS670 output goes tri-state.
OR
  You keep using grant's logic and have ROMDisabled connected to 74LS670 tri-state input pin 11.

Just noticed this, C, and your comment about needing the 74LS670 as it would be quicker.  Would the LS version work okay with the rest of my chips which are all HCT components?

Also - the comment re: the 273.  I've not got a 273 in the current MMU design (see post above) - would the current design do what I need it to do and switch the ROM so I can remove Grant's ROM switching circuit?
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #34 on: November 12, 2017, 11:40:32 PM »
The 74HC670 looks to be slower then the 74LS670.
So both would work an slow Z80 clock speeds.
As you increase the Z80 clock speed, you have less time from when the Z80 address lines are changing and then MREQ going active.

So at some Z80 CK speed  slower stops working correctly. Faster gets you higher clock speeds
I have not added up the times but I think 2 & 4 meg should be ok

At some point, you would need to add a time delay to MREQ to go higher.
Two inverters are a time delay.
The 74LS670 is not for a 16-20 meg z80 clock if you want fast computer.

Think you will be fine and rememver easy to change on breadboard.

HCT is a TTL level CHIP the 74LS670 will be fine here.

If you have two 273's and 2 253's you have what you need.

A change to 74LS670 is very small. need 74LS670 and pull-ups.

A 273 and inverter will work to control tri-state
Grant's rom disable would work.


Some clean up of grant's would make playing with hardware easer.

More quick
 
« Last Edit: November 13, 2017, 02:34:49 AM by C »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #35 on: November 12, 2017, 11:46:27 PM »
Good morning nockieboy

See if I can make it better

Your last drawing is the 74ls670
Note that you need the LS not the HC

The Gr pin  of 74ls670 is like the EO pin of the 253 in  your previous drawing

Ra & Rb are the select inputs of the 253

For the 74LS670 the 253's data inputs do not show. But both are connected to storage.

74LS670 Qn outputs are same as 253 outputs. With just 2 outputs ber 253, need two to get four outputs.

So 253 pins match 74LS670 With storage connection shown for 253 and hidden inside for 74LS670

To get the 273 to match it's four 273's but only 4 input & output bits.

74LS670 Dn inputs are the 273 data inputs

The 74LS670 has part of address decoder you need to connect to get 4 273's working
This is one half of a 139 decoder.
74ls670 Wa,Wb are decoder inputs of 139
The 139 decoder has an enable pin, the 273 have a Ck pin, These are all connected together and are these become Gr input of 74LS670

Just noticed
See Gw & Gr in some data sheets and Ew & Er in others they are same pins.

So The four chip version lets you see some of what is inside the 74LS670

If you do not use the clear input to 273 and use the tri-state output of 253 you have a 74LS670

 

« Last Edit: November 13, 2017, 02:38:08 AM by C »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #36 on: November 12, 2017, 11:53:21 PM »

PULL-UP- resistors
The Pull-up resistors put a valid logic level on inputs of memory chips isstead of letting them flop around.
Connect to Output of MMU
Qn on 74LS670
Outputs of 253 for that version


 

Connect to address inputs of your memory chips
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #37 on: November 13, 2017, 12:02:23 AM »
Q1: The pullups/pulldowns go on the four extended address bits EA14-EA17 on the physical memory side of the MMU circuit.  If all the memory chips and logic that has those lines as inputs have normal CMOS input thresholds (20%, 80%) you can use pullups and pulldowns to set the default value of that nibble freely.  However if any of them have TTL compatible input thresholds you should *ONLY* use pullups, which forces you to put the ROM at the top of the memory map and the boot block at the top of the ROM as 'C' has been recommending.   Because the extended address bus is inactive from /RESET until your code enables it, the pullups/pulldowns can be a relatively high value as their lines are static until enabled.  10K should work nicely.  N.B the effect of switching back to BOOT mode on a screaming fast Z80 system would be unpredictable.   10K might not pull the lines to the correct level in time for the next /M1 instruction fetch.  Don't do that unless you are already executing from the BOOT block mapped in page 0.

Q2: Propagation delay in the I/O address decoder is a bitch.  Personally, I'd start with a pair of 74AC138* chips totally decoding the high nibble of the 8 bit I/O address (A4-A7), + /IORQ (to /E1).  Connect A7 to /E2 of the first chip and E3 of the second. Don't include /M1.  Its only active with /IORQ in IM2 interrupt acknowledge cycles, with /RD and /WR inactive.   That will give you 16 active low lines that each correspond to 16 consecutive I/O addresses.   Within each 16 address block, you can then decode right down to single address level and include /RD or /WR with another '138.   

On speed of 74xx670 chips - they aren't that fast - if you are building a screaming fast system using a Z80 clone possibly with interleaved video memory access you need to use something much better.  That's what drove the topic I originally pointed you at towards '486 era cache SRAM to do the MMU mapping, in spite of the complexity of it only having a single address bus and data bus.  There was just no other way of getting the MMU propagation delay down to 10ns while retaining 5V logic. 

If you need to interface Z80 peripheral chips that directly take /IORQ, /RD and /WR, the above doesn't give enough setup time for /CS because /IORQ was included in the first decode.   A single '138 directly on the address bus lets you decode 6 bits, with the constraint that one must be high and two low, and will support eight Z80 peripheral chips, with A0 and A1 passed through to the chip for register selection.

Take care to avoid address conflicts between the raw I/O decoded addresses and addresses decoded for Z80 peripheral chips.

* 74AC series parts have brutally fast edges on their outputs.  6ns is typical.  Use a ground plane and make sure each package has good local decoupling.  You may need to add source termination and RC load termination of long lines to reduce reflections and control EMI.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #38 on: November 13, 2017, 12:12:56 AM »

1) Where do those pull-up/downs go to select ROM bank 0 (lowest 16K in ROM) for Area 0 (lowest 16K in memory space) and RAM bank 1 (16-32K in RAM) for Area 1 (16-32K in memory space) on power-up?? (That's the minimum requirement to get the monitor running - once running, it can set up the memory as it likes.)

You only get ROM at low address range if you use pull-DOWN resistors.
Pull-Down not a good idea when using LS or HCT

Do this
make two versions of your power up boot program
Put one copy at 0-16k in your ROM
Have it stat "From Low Rom Area"

Put a second copy in your Rom at the highest 16K area
Just changet "From Low Rom Area"
to
   "From HI  Rom Area"

your Boot ROM is now good if your code is good.
Will work with Grant's
Will work with Expanded 0-16k
Will work with Expanded 256-16k to 256k the highest block

The code is the same only the message changed.
 
The following users thanked this post: Ian.M

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #39 on: November 13, 2017, 02:13:49 AM »
Address decoders

To keep math easy need some numbers, these ARE MADE UP.

When data changes on a bus, any buss, it is a BIG MESS.

First you have the device trying to change the data not changing it at same time.
Then you have differences in signal paths, load on pins, and a whole bunch of other things.

Safe thing to think
Buss has stable data.
When bus starts to change, the data goes to crap, IT is UN-KNOWN.
Some time later the data lines get to a stable state, but NOT at same time.

If you have a decoder chip looking at the buss, many of the outputs will bounce up and down. With out careful design of decoder some outputs could take less time to decode then others.

The decoder chips like the 138 are built to handle this problem but needs a signal stating that BUSS is now stable.

For Z80 this is MREQ or IORQ for address buss.
Now at a slow Z80 clock speed the address buss should become stable a long time before MREQ or IORQ
It is not hard to delay MREQ or IORQ, but you can not make these happen before they do.
Now if you KNOW that MREQ or IORQ happens before the address buss is stable, it is not a problem if you add the correct delay to fix this.
If you look at Z80 Datasheet, At high Z80 clock speeds the 20m Z80 does this.

What you want is a nice clean change on the CS pin of your SIO or memory chip.
To get this MREQ or IORQ should enable the outputs of the decoder chip that is connected to the SIO or memory chip.
Look at the Z80 peripheral chips, they want CS to be a range of 4 I/O addresses.
So
  A0 & A1 goes to Z80 peripheral chip
For full address decode A2,A3<A4 goes to 138
The final output enable should connect to IORQ
This leaves A5,A6,A7 not decoded yet for full address decode.
Lets use some simple numbers to make the picture clear

Lets say that it takes 15 Ns for output to change based on A2-A4.
and it takes 10 ns IORQ change to get to outputs to enable them

As long as IORQ happens 5 ns after the addresses have stopped changing you get no glitches on the output. A glitch is the output going low and back high in this case before the stable low level.

Now to get full address decode you need a second 138 for A5,A6,A7
With the output of this chip going to one of the first enables you have the following
A5,A6,A7 take 15 ns to change first 138 output then 10 Ns enable time of second 138.

with this logic A5,A6,A7 need to be stable 25 ns before output to SIO.
This is 15 ns before IORQ.
If you connect IORQ to A5,A6,A7 you create a problem
  output of this decoder is 10 ns after IORQ & another 10 ns delay happens with second decoder. The CS of the SIO is now delayed 20 ns instead of 10 ns

Now some chips when used for OUTPUT also need WR
Chips like 273 need this.
The 74LS670 needs this.
Connecting a AND gate to combine WR AND the address + IORQ above will add the AND gate delay time to the signal.
If you can connect WR to the decoder you can save this time.

So when designing a computer it is not just getting the logic correct.
It is getting the Logic correct with out GLITCHES.
It is getting the timing correct to prevent glitches and making the connected chip happy.
AND Z80 happy with the connected circuit.

Note that I used 10 ns and 15 Ns above, You always want some stable time and not run on ragged edge of times. 

Now if you have a need for just IORQ enabled chip selects and IORQ + /wr chip selects, you might want to run parallel decoders to do this.
Going parallel means that the Z80 has to drive more chips which slows changes but can save having to go through more levels of decode.
The Z80 has a limit on what it can drive

Remember that time is not just hardware.
Good hardware lets you use less software to get the job done.
Less software = faster computer.

Now in past I talked about software
Last I saw your SIO init code it had data values embedded in the code.
lan.M's example code does this.
It is easer to show details when doing this, but you can not easy have program change the data.
The data is all over the place when you need a change and often this means you need to run the assembler again.

This is where having data tables is your friend.

For your SIO init code
Load register with address of a table of bytes to be sent to SIO.
Load a register with What SIO
You can now have a common sub that will INIT any SIO.

For MMU this can also be handy
The same sub could handle part of the inital load to MMU
And same sub could then be used when areas need to be changed.

If what CP/M3 wants does not match what your MMU needs then the table can handle most of the problems.

So for MMU
First thing is get ONE MMU working. This is the big step.
After that it is small change for the different versions of MMU.

You could have software that will work with any version with out software change.

When you look at the old ways, try to understand then in the time when used.
Is there a better way using todays chips.

An example
   my first ram memory board used 2kx1 chips and cost a lot.
A simple 8k memory board was 2kx1 X 8 X 4   That is 32 chips.  This board ran HOT, it was almost a bread toaster.
When the 2k x 8 chip came out, that board saved a lot of chips and a lot of power.
So when you used 128k chips it was a smart move and saved you money. Now if you think about it 512k could be better yet.

The 48k bank select was a way to got old computers to work with few changes.
Big thing was Many boards with only a 16 bit address bus and no easy way to add more address lines.
Having 4 16k areas lets you look like you have 48k banks and use the huge memory chips of today. That old hardware will becomes a mess when connected to huge memory of today.


 





   
« Last Edit: November 13, 2017, 02:32:24 AM by C »
 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #40 on: November 13, 2017, 09:42:42 AM »
Okay, here's the updated schematic with the 74LS670:



Are the pull-ups correct?  They should make the very top 16KB bank of the 128KB ROM appear in Area 0 (bottom 0-16K page of memory space) on power-up.

The issue I can see is how do I set the default power-on state of Q4 (the RAM/~ROM select line) - technically it should be pulled low, but apparently that's a 'bad thing'TM?

Let me know what changes I need to make to the MMU circuit above (if any), then I'll start looking at the IO decoder circuit as I'm going to have to make changes there also.
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #41 on: November 13, 2017, 12:28:42 PM »
Resistors on all four pins Q1-Q4

The pull up on Q4 should enable ROM.

=====

Gr is High for tri-state so at power up reset the FF output connected should a 1 HIGH

Here you have a lot of options using the 74
Would be nice when you write to this port for D7 to be low normally so when clocked by I/O write you will get a state on the two outputs. Here you want a low level on
D7 low on I/O write which makes  Gr  = 0   The Q output.

At power UP you then  write the first 4 times with D7 high.
Then turn on MMU by a write with D7 low

So with this being what you want for normal, you have a choice of preseting this chip on power up or clearing this chip on power up.
So if I am thinking correct Power Up preset Sets the FF to cause Q= 1 -> Gr which tri-states 74LS670 outputs.
So if your RESET goes Low at power up and is connected to preset you are good.

This matches lam.M

From what I see in drawing add the Q4 resistor

 You match lan.M post for port use.

======

In place of 74
Now If you are going to have a 273 that is reset at power up you could use a bit there in place of 74 FF. BUT the 273 only resets to 0 so you would need and inverter between 273 bit and Gr.
And to be complete you could use grant's existing logic to do this. Not my choice unless you want to use it while making the change.

Would suggest you put this on separate breadboard or on memory breadboard.
You could leave the Q1-Q4 disconnected from memory and do some tests to verify you have built this correctly.

========
Decoder
   remember that you do not have to use all outputs.
If you have nothing connected then nothing will respond to that address.
You could build a new decoder and slowly move outputs from U5 to new.

In the future, think you would like a decoder for
One address I/O Write      (273,374  & lan.M MMU )
One address I/O Read
Four address I/O  for (SIO, CTC PIO)

Then I think the CF card is using 8 addresses. Would need to look in the software to verify it is using 8 and not less.
You could OR two 4 address outputs, but Need to test to see if it works with added delay of OR gate.

Need to keep track of what is connected and how much load each thing adds to Z80 output. Z80 has limited output.
« Last Edit: November 13, 2017, 12:30:41 PM by C »
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #42 on: November 13, 2017, 03:53:45 PM »
No. the ROM has /CE and the RAM has CE2.  Pulling up EA17 (aka Q4, RAM/ROM_SELECT) would select the RAM at booot - pretty pointless.  However the RAM and ROM *PROBABLY* have CMOS input thresholds.  If so, a pulldown is legitimate.   If they have TTL thresholds, (or worse there is an actual bipolar TTL gate input on that line), then stick a pullup on Q4 and follow it with a CMOS inverter to drive the ROM /CE and RAM CE2.  That would also swap the positions of the ROM and RAM in the memory map.

If you go with my suggestion for decoders, you get at the top level 16 address blocks, so no problem hooking up a CF card with three address lines.  However a CF card has TWO chip select lines, that select different register sets so you still need to combine A3 with the 16 address block /CS from the top level '138.
« Last Edit: November 13, 2017, 04:07:08 PM by Ian.M »
 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #43 on: November 14, 2017, 05:25:52 AM »
No. the ROM has /CE and the RAM has CE2.  Pulling up EA17 (aka Q4, RAM/ROM_SELECT) would select the RAM at booot - pretty pointless.

Yeah, that was my concern. Could always use an inverter, but I'd be miffed if I have to add another chip to use one inverter on it...  :palm:

However the RAM and ROM *PROBABLY* have CMOS input thresholds.  If so, a pulldown is legitimate.   If they have TTL thresholds, (or worse there is an actual bipolar TTL gate input on that line), then stick a pullup on Q4 and follow it with a CMOS inverter to drive the ROM /CE and RAM CE2.  That would also swap the positions of the ROM and RAM in the memory map.

Okay well, this sounds like it could make a huge difference - I'm going to pour over the datasheets for the RAM and ROM tonight to see if I can work out if they're CMOS or not.  Will it say 'CMOS/TTL-level inputs', or am I looking for something in particular?

If you go with my suggestion for decoders, you get at the top level 16 address blocks, so no problem hooking up a CF card with three address lines.  However a CF card has TWO chip select lines, that select different register sets so you still need to combine A3 with the 16 address block /CS from the top level '138.

I was a little befuddled by the decoder explanation, I'll admit - I think the considerations around potential timing issues are worrying and distracting me - but I'm not giving that much thought at the moment as I want to pin down the MMU function and design first, then I'll turn my full attention to modifying the IO decoder.

Gr is High for tri-state so at power up reset the FF output connected should a 1 HIGH

Here you have a lot of options using the 74
Would be nice when you write to this port for D7 to be low normally so when clocked by I/O write you will get a state on the two outputs. Here you want a low level on
D7 low on I/O write which makes  Gr  = 0   The Q output.

At power UP you then  write the first 4 times with D7 high.
Then turn on MMU by a write with D7 low

So with this being what you want for normal, you have a choice of preseting this chip on power up or clearing this chip on power up.
So if I am thinking correct Power Up preset Sets the FF to cause Q= 1 -> Gr which tri-states 74LS670 outputs.
So if your RESET goes Low at power up and is connected to preset you are good.

Sorry C, I'm struggling with the English in this one. So you're saying that at power-up, ideally I want the 74 flip-flop to be outputting HIGH to tri-state the 670's outputs?  Then I guess the pull-ups will work their magic and the top bank in ROM will appear in the first area of memory space?

(How) can I preset the output of the 7474? The design only uses D0-D5 currently - how would I implement your suggestion about using D7 to enable/disable the 670?

In place of 74
Now If you are going to have a 273 that is reset at power up you could use a bit there in place of 74 FF. BUT the 273 only resets to 0 so you would need and inverter between 273 bit and Gr.
And to be complete you could use grant's existing logic to do this. Not my choice unless you want to use it while making the change.

No, I'm going with this design currently so I won't be touching any 273's.

Would suggest you put this on separate breadboard or on memory breadboard.
You could leave the Q1-Q4 disconnected from memory and do some tests to verify you have built this correctly.

Absolutely - sounds like a good idea.  :-+

Decoder
   remember that you do not have to use all outputs.
If you have nothing connected then nothing will respond to that address.
You could build a new decoder and slowly move outputs from U5 to new.

In the future, think you would like a decoder for
One address I/O Write      (273,374  & lan.M MMU )
One address I/O Read
Four address I/O  for (SIO, CTC PIO)

Then I think the CF card is using 8 addresses. Would need to look in the software to verify it is using 8 and not less.
You could OR two 4 address outputs, but Need to test to see if it works with added delay of OR gate.

Need to keep track of what is connected and how much load each thing adds to Z80 output. Z80 has limited output.


Another good idea re: building a new decoder and swapping lines over to it from U5 one by one. I'm running out of space though!  :o

Currently I've got the ROM/RAM select circuit, SIO/2, CTC, PIO and CompactFlash running from the 138 IO decoder.  I'll be adding the AY PSG after the MMU, so that's two more things to add.  These select lines are all driven by the 138, though - the Z80 (it's CMOS - Z84C008) itself drives the address and data buses and a handful of HCT logic chips, but I hear you loud and clear.  I have plans to add buffers to the address and data buses, but won't these add a delay into the circuit?
 

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #44 on: November 14, 2017, 06:04:17 AM »
However the RAM and ROM *PROBABLY* have CMOS input thresholds.  If so, a pulldown is legitimate.   If they have TTL thresholds, (or worse there is an actual bipolar TTL gate input on that line), then stick a pullup on Q4 and follow it with a CMOS inverter to drive the ROM /CE and RAM CE2.  That would also swap the positions of the ROM and RAM in the memory map.

Errr... okay, both the datasheets for the ROM and RAM mention TTL IO compatibility... not sure if that is a definite no to the question of whether they have CMOS input thresholds, as I don't know what I'm looking for.  Here's the relevant datasheets, anyway:

ROM: 39SF010A EEPROM
RAM: AS6C1008-55PCN SRAM
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #45 on: November 14, 2017, 06:11:18 AM »
TTL thresholds, and the RAM's logic 0 threshold is only 0.6V, so you *should* use an inverter.   You can use any inverting gate with its inputs strapped together.    If you try to use a resistor it will probably be unreliable.
 
The following users thanked this post: nockieboy

Offline nockieboy

  • Regular Contributor
  • *
  • Posts: 244
  • Country: gb
Re: Z80 memory banking for 128K - MMU design
« Reply #46 on: November 14, 2017, 10:23:15 AM »
Okay, so this is how the MMU is looking now:



Can I just confirm what the memory map now looks like and that the IO addressing is the same as you previously stated, Ian.M?

So RAM is now 0-128KB and ROM effectively now occupies 128-256KB in physical memory space?  On power-on, the Z80 will see the top 16KB bank (112-128K) of ROM as area 0 (0-16K) in memory space?
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #47 on: November 14, 2017, 11:08:38 AM »

Yes

A14 & A15 connect to 74LS670.
Output of 74LS670 is disabled. (rri-state)
Resistors supply high address lines levels.

So At power up Z80 sees four copies of the top 16k bank

You write good data in to 74LS670 with it still disabled.

You then enable 74ls670
Z80 A14 & A15 noiw controls what is on the 4 address lines via 74LS670

 

Offline C

  • Super Contributor
  • ***
  • Posts: 1049
  • Country: us
Re: Z80 memory banking for 128K - MMU design
« Reply #48 on: November 14, 2017, 11:42:42 PM »

You could have a lable on Q4      EA17

Might make it easer for some one to understand.  Q4 is an expanded address line, here used as ram/rom select.

How you doing understanding a MMU?



Now some things you might not have noticed.

There is JEDEC Standard for a – 32-pin PDIP
Part of standard covers the pins, part software for non tam/rom , parts like flash eeprom.

The datasheet for your flash rom table 4 shows this for a 32 pin socket.  If you were planning a PC board, with some care, it could be used with many sizes of chips.

Note the software steps for your Flash Rom to write data again part of JEDEC

So table 4 gives you a list of pins to check how the use of pins change with size
pin 30, pin 1 , pin

I would wire up pin 31 to both chips so in the future you can write to flash using Z80.

You are using a inverter here. If you had more 128k chips, you should use a decoder like 138.

Older memory chips do not support the way these chips are used and you would have MREQ connected to decoder enable instead of where MREQ is connected now.
 
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 5750
Re: Z80 memory banking for 128K - MMU design
« Reply #49 on: November 15, 2017, 12:28:10 AM »
A cheap and easy way of adding more FLASH ROM would be to connect the remaining unused data bit at the MMU port address to the other half of the boot mode flipflop chip, in exactly the same way.   Then instead of the inverter  between  EA17 and the /CS line to the ROM, take the Q and /Q from the new flipflop, each to one input of a pair of NAND gates, with their other inputs from EA17.  That gives you two ROM /CS signals, each suitable for a 128K chip without increasing your glue logic chip count.   At boot, the flipflop would be set, so the NAND fed with Q would generate the active /CS. 

It would have the limitation that you cant map blocks from both ROMs simultaneously, and when you switch that bit, *ALL* ROM mapped pages flip to the other ROM chip, but that can be handled by *either* duplicating the critical boot block and BIOS in both chips, leaving you with 224K free, *or* copying the BIOS to RAM, giving you 240K free. Both give  enough space for a  CP/M Plus system + selected utilities on ROMdisk.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf