MMU addition

[Robb Bates]

Wayne,

I'm working on a bare bones Z80 computer that uses a PLD as an MMU.

I'd like to know in what all sections of the hbios.asm I need to set the bank selection.

Currently I have this code:

HBX_BNKSEL_INT:

;

#IF (MEMMGR == MM_TINNYZ80)
AND %10001111
OUT (MPGSEL_0),A
RET
#ENDIF
;

Of course, I'll set MEMMGR and MPGSEL_0 in the appropriate config files.

Is that the only place I need to do that?  Or are there others?

Don't worry too much about the actual hardware, as I believe it's correct.  I just need to know when to access the bank select register.

Thanks,

Robb

[Wayne Warthen]

Other than the routine you have already handled, you do need to preset the initial memory map at startup in the section called "PLATFORM MEMORY MANAGEMENT INITIALIZATION".  In this section, you need to do whatever is needed to ensure that the first 32K of ROM is mapped to the first 32K of CPU address space (probably already is at reset).  You also need to map the last 32K of RAM to the top 32K of CPU address space.

Thanks, Wayne

[Robb Bates]

As far as the hardware goes, I have a PLD with a register implemented in it.  I output the accumulator which has the value of the bank selection HB_CURBNK loaded just prior to my routine, and output bits 0-4 and 7 to my PLD.  Bit 7 selects RAM if high and ROM if low. Bits 0-3 are latched on output and translate to select the 32k bank on the 512K RAM/ROM.  Bit 4 will enable the onboard memory if 0 and not select it if it's 1, allowing for expansion.  It also selects the highest bank of RAM if the CPU A15 is high.  At reset, all register bits are set to 0, which selects the first bank of the ROM.

This currently assumes 512k RAM and ROM.  I have the ability to expand that, but will need to tweak the hardware and software a little.

So since everything that the PLATFORM MMI routine requires is already done in hardware, I guess I don't need any code there.

All the above may not be too clear, and I can expound on it if needed, but assuming I got the hardware correct, the upper 32k of the CPU address space will always map to the highest 32k bank of the RAM chip and at reset, the lower 32k of CPU address space is mapped to the first 32k bank of the ROM chip.  And then whenever HBX_BNKSEL_INT is called, the bank select latch on my PLD selects the appropriate 32k bank of the RAM or ROM, which is then mapped to the lower 32k CPU space, all based on the accumulator which has  HB_CURBNK in it.

Thanks,

Robb

[Sergey Kiselev]

Robb,

I am not sure how far are you in your hardware design. If you like you can make you MMU compatible with somewhat reduced Zeta SBC V2 MMU, which is also used in RC2014 512K ROM/512K RAM card. It is already supported by RomWBW, so you'd avoid adding support for yet another MMU.

In Zeta SBC V2 MMU, the memory is divided to 16 KiB pages, and each one of four 16 KiB "banks" of Z80 can be mapped to any page. The MMU uses 5 registers - 4 registers for page numbers for each one of the banks, and one single bit to enable paging (if disabled, the first 16 KiB of ROM is mapped to all banks).

The registers in the RC2014/RCBus implementation are mapped as follows:

0x78 - MPGSEL_0 - page select for bank 0

0x79 - MPGSEL_1 - page select for bank 1

0x7A - MPGSEL_2 - page select for bank 2

0x7B - MPGSEL_3 - page select for bank 3

0x7C - bit 0 - Memory paging enable: 0 = MMU disabled, 1 = MMU enabled

Now, here is the simplification devised by Steve Cousins (e.g., see his SC714 project, also used in my Z80-CPM module):

• Uses 32 KiB/32 KiB split, just like yours
• Maps higher 32 KiB of RAM to high 32 KiB of the Z80 address space
• Uses only one register
• Still compatible with RomWBW

The only register is mapped to both 0x78 and 0x79 - the address line A0 is not checked / ignored.

The register has the following bits:

• bit 0 - Not implemented / ignored
• bit 1-4 - Memory addresses MA15 - MA18 for the lower 32 KiB bank
• bit 5 -  ROM/RAM select, 0 = ROM, 1 = RAM. Technically you can think about it as a MA19 too, assuming that the memory is 1 MiB

If you like to expand the MMU, you can add 2 more bits to it, allowing for 4 MiB of total memory.

It is still compatible with RomWBW, because RomWBW always writes two consecutive page number to MPGSEL_0 and MPGSEL_1, even and odd, respectively. It writes MPGSEL_2 and MPGSEL_3 only at boot time, and sets them to the last two pages of RAM. This MMU is hardwired to do that, and writing non-existent registers is ignored.

This seems to be a really small change from your implementation. Simply moving bits in the MMU register.

Thanks,

Sergey

[Robb Bates]

I had asked about why go with 16k banks before.  But made the decision to stick with just 32k banks.  My main goal is to stick with RomWBW CP/M 2.2 and ZPM3 for the time being.  As I understand, the 16k banks are mainly for other OSes.  If I want to explore those I'd just use my full Zed Pro.

The primary goal of this project is just to help me wrap my head around the Z80 and the relatively simplistic CP/M implementation.

My 22v10 PLD is maxed out with the current MMU set up... although I think I MIGHT be able to implement 16k banks with different presumptions about expansion capabilities.  But I'll burn that bridge when I get there.

I'll take a closer look at your suggestions and see how hard those might be to implement.

Thanks,

Robb

[Ed Silky]

Hi,

I'm designing a board with the ROM being an EEPROM and I want one of the bits in the MMU to be 'write enable', so I can map the ROM in and write to it, but have a 'safety bit' that needs to be enabled. I currently have it designed so that bit 7 is the enable. I'm also using 8k banks to give more granularity, but maybe 16k is adequate?

Advice from the group is appreciated.

-Ed

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/045d3029-57ae-4ecb-84d8-de6a703f322cn%40googlegroups.com.

[Sergey Kiselev]

On Thursday, September 4, 2025 at 8:12:29 AM UTC-7 Robb Bates wrote:

I had asked about why go with 16k banks before.  But made the decision to stick with just 32k banks.  My main goal is to stick with RomWBW CP/M 2.2 and ZPM3 for the time being.  As I understand, the 16k banks are mainly for other OSes.  If I want to explore those I'd just use my full Zed Pro.

The simplified one I described has 32k banks. 

The primary goal of this project is just to help me wrap my head around the Z80 and the relatively simplistic CP/M implementation.

My 22v10 PLD is maxed out with the current MMU set up... although I think I MIGHT be able to implement 16k banks with different presumptions about expansion capabilities.  But I'll burn that bridge when I get there.

I'll take a closer look at your suggestions and see how hard those might be to implement.

 

Shouldn't be difficult. Just remapping some bits in the register. The advantage is that no changes would be required to RomWBW.

 

[Sergey Kiselev]

I'm designing a board with the ROM being an EEPROM and I want one of the bits in the MMU to be 'write enable', so I can map the ROM in and write to it, but have a 'safety bit' that needs to be enabled. I currently have it designed so that bit 7 is the enable. I'm also using 8k banks to give more granularity, but maybe 16k is adequate? 

More modern EEPROMs (e.g., Atmel 28C256) have SDP (software data protection), and all Flash ROMs require issuing commands before writes are enabled. So I am not certain that an additional safety bit is required. Some boards have a physical jumper for write protection. It might make sense to prevent user errors...

Regarding memory split 16 KiB * 4 seems to be adequate for most uses - CP/M, MP/M, FUXIZ, etc. It is not very likely that CP/M (RomWBW) will benefit from smaller pages, as it only needs 32 KiB / 32 KiB split. But MP/M seems to require at least 48 KiB / 16 KiB split or 16 KiB pages, and FUZIX uses 16 KiB pages.

 

[Tadeusz Pycio]

The smaller the page size, the greater the software overhead required to handle it. Dividing into 16kB pages is the most universal solution, and if we only want to use RomWBW, 32kB is the best option. I use an MMU module based on the 74HCT612 chip, which supports 4 kB pages, but in practice I do not use such a fine division.

[Alan Cox]

A lot depends on the OS and how it uses memory.

OS/9 for example on 6809 really wants 2K or 4K pages but it uses that to share code between programs and many other memory saving activities. Using it effectively with a Z80 is harder (no easy position independent code or data) and you'd also really need something like a 32bit compiler that could use multiple pages and banks automatically as DOS ones use segments. Those kinds of tools never existed in the CP/M world although some of this technology did exist by the end of that era for Z180 and Rabbit processors for embedded use.

[7alken]

hi all, if I even can help (with theory) here, just yesterday drafting some more details about "extended/unified Zeta V2" as its really nice ... by allowing full 8bit for # of pages, with possibility to switch page/bank sizes, say 4 options (where I omitted 32k as too big on 8bits, no problem to use 2 16k banks here, not big overhead, but allow also 8k 4k and those 2k banks - ya then its 32 areas, overhead - but this mostly for faster 16/32bit CPUs where smaller banks are enough + allowing to remap using such "Z2X" also regular out/in opcodes and so IORQ for MMIO unified possibly using such MMU to extend already very full 8bit IO space of rc2014/RCBus .,.. ??) hope its at least partially understandable ... and not sure if such thing can fit into tqfp/plcc - say epm3064/7064... I will be happy if real experts can advice here, or if you are designing something new, try to unify/extend Z2 concept, sure ... 

here some notes about levels, as max3000 is 5V IO tolerant, but requires 3V3 max Vcc, so only this as HI level ... BillShen uses epm7064/7128 though ... 
https://chatgpt.com/share/68ba1715-07e8-8000-b49b-6c74c8b8810f
P.

[7alken]

umm, Robb, excuse me, I understand you have your own reasons for use what YOU have in mind :-) ... I tried to chat with Lyra little deeper about Zeta V2 as-is inside say PLCC44 max3000/max7000 ... with possible ideas how to extend IO space too in context of rc2014/RCBus (that IORQ can be split in half also to have stable IO for crucial MMU and even redirected out/in to the aliased MMIO ... and Lyra thinks it can fit inside that single package ... for some expert ... probably )); so ...as there is open source, open hardware, ... I treat this as "open consulting", or "open thinking" ... something like this ... not easy to pass content of brain around the globe easily ))) but if it can spark """something""" elsewhere, hopefully good ... cheers ))

[Ed Silky]

I have multiple SST39SF040 chips lying around, so I plan to use one of them. I suppose that I can just rely on the software sequence for protection. I don't believe the 74HCT612 is still available. I'm using 4 74HC670's to provide 8 8k pages. I haven't finished the design, so I could reduce the chip count and use 2 74HC670's for 16k pages. I was thinking that MP/M could use 8k pages, but maybe I'm not correct on that. On some dedicated hardware that I had available in the 80's, I wrote a multi-user application that took advantage of 2k pages. All per-user data was accessed from a bank using IX and IY addressing and a regular interrupt did context switching. I'm not sure I would do anything like that now, I'm mostly wanting to design, build, and program something for the fun of it. I have a Z80 ICE that I designed in the late 80's and the company let me take one with me when I left. I really just want something to plug it into and bring it back to life, but I figured I would do something a bit more complex than just a Z80, some RAM, and a ROM.

-Ed

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/0d1e40ce-d939-49cd-a245-bb7d2e9262d9n%40googlegroups.com.

[Alan Cox]

On Fri, 5 Sept 2025 at 06:09, Ed Silky <aes...@gmail.com> wrote:

I have multiple SST39SF040 chips lying around, so I plan to use one of them. I suppose that I can just rely on the software sequence for protection. I don't believe the 74HCT612 is still available. I'm using 4 74HC670's to provide 8 8k pages. I haven't finished the design, so I could reduce the chip count and use 2 74HC670's for 16k pages. I was thinking that MP/M could use 8k pages, but maybe I'm not correct on that. 

MP/M wants a high common and low paged area. It'll happily use 16K banked (4 x 16K as 16K / 48K with a 48K TPA but pushing much above that is tricky, and it was some of the CP/M compatible clones that could do this well - ones we've no longer got source code for unless someone strikes lucky one day.

Fuzix can use 8K/56K but the gain for 8K pages on Z80 is pretty tiny.

 

[Ed Silky]

Thanks for the advice. I'll change the design and remove some chips.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CAK9X0%2BtSmB44s36GVfKQmOeX%2BXbtshpgCUvfio2gtFPidrdpmw%40mail.gmail.com.

[Sergey Kiselev]

On Thursday, September 4, 2025 at 3:52:34 PM UTC-7 7alken wrote:

hi all, if I even can help (with theory) here, just yesterday drafting some more details about "extended/unified Zeta V2" as its really nice ... by allowing full 8bit for # of pages, with possibility to switch page/bank sizes, say 4 options (where I omitted 32k as too big on 8bits, no problem to use 2 16k banks here, not big overhead, but allow also 8k 4k and those 2k banks - ya then its 32 areas, overhead - but this mostly for faster 16/32bit CPUs where smaller banks are enough + allowing to remap using such "Z2X" also regular out/in opcodes and so IORQ for MMIO unified possibly using such MMU to extend already very full 8bit IO space of rc2014/RCBus .,.. ??) hope its at least partially understandable ... and not sure if such thing can fit into tqfp/plcc - say epm3064/7064... I will be happy if real experts can advice here, or if you are designing something new, try to unify/extend Z2 concept, sure ... 

A bit difficult to think about a use case where such page size flexibility will be desired. I guess, given smaller page sizes, something like FUZIX can use these pages for shared memory, e.g. for libraries?!

It will also complicate the hardware a quite bit for a few reasons:

- The smaller page size is, the more page registers the MMU will need.

- More page registers require more I/O space... Unless the MMU registers are memory mapped.

- Smaller pages and an 8 bit page register size limit the total addressable memory size. Page registers don't have to be limited to 8 bit, they can be 16 bit. But that would require two I/O writes to update and even more storage...

- Flexible page size requires additional registers and logic to configure the page sizes. I imagine there could be some kind of "mask" register that defines what bits of the page register are being used, and what are being ignored...

As an example, an MMU with 2 KiB page size and 8 bit page registers will need to have 32 registers of 8 bit. The total of 256 bit... If I am not mistaken bigger CPLDs, such as EPM7128SLC84 or AS1508AS-J84 have only 128 "registers" (one bit D-FFs). It will also limit the addressable memory size to 512 KiB, since the MMU will expand the top 5 bit of the address bus - A11-A16, to 8 bit, e.g., MA11- MA18

An MMU with 8 KiB page sizes might be a bit more reasonable and realistic, as it will need 8 registers, and will allow addressing 2 MiB of memory using 8-bit page registers, and will even fit into one of these bigger CPLDs.

Regarding a CPLD based MMU implementation, I've done it before. 

My RCBus Z80 + CPLD + Memory module project is here: https://github.com/skiselev/Z80-512K/, and if you're interested, I have some for sale :)

I used an Atmel ATF1504AS CPLD. It is pin compatible with Altera EPM7064SLC44. I used Altera's Quartus software to program them, and then POF2JED utility to convert from Altera to Atmel format.

The MMU in this project is Zeta SBC V2 compatible and uses 16 KiB page size with 4 * 6 bit page registers (higher 2 bits are ignored). This is both due to the number of macrocells - 32, and limited number of pins the CPLD has - 44 pin, with some used for JTAG, power, clock, and reset.

- Sergey

[Ed Silky]

Thanks. I'll take a look at your project. Given the input from you and others, I've already changed my design to 16k pages. In the 80's, when I designed communication boards and disk-controllers that used the Z80, we used smaller pages, generally 2k or 4k, to be able to transfer a couple tracks to/from or to contain 4 to 8 communication buffers. But a lot of that was because a different part of the hardware would access it while it was paged out of the Z80's space to transfer into or out of it and then signal the Z80 that it was ready/done. The Z80 would page it in and access it while the other part of the board used a different page (not mapped into the Z80 space) to fill/empty. We would cycle through multiple pages to keep everything busy.

Since ROMWBW and other things that I have checked into seem to like 16k pages, that's what I'll do.

-Ed

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/9e4ffb82-98d8-492c-9a17-f03513b4add1n%40googlegroups.com.

[Ed Silky]

I also want to mention that if you need to be able to select a large number of page registers for writing, you can use a single I/O address for an enable and use the upper address bits to select the register. We didn't do that for memory page mapping, but we did do it on some of our communications boards where we needed many I/O locations for channels and didn't want to take out of our memory space.

-Ed

[Mark Pruden]

> Since ROMWBW and other things that I have checked into seem to like 16k pages, that's what I'll do.

I think you will find RomWBW natively uses 32kb Pages, not to say 16Kb wont work, but just so you are aware.

[Jonathan Harston]

Coming late to this conversation, but this is what i designed for a

mmu for a Z80 40 years ago:

https://mdfs.net/Info/Comp/Z80/Circuits/1MbMem.gif

I designed the I/O such that writing to port Nxxx controlled

the mapping of memory at Nxxx. (ie, OUT (&3xyz),n where xyz is

the decoded paging address controlled the mapping of memory

at &3000-&3FFF.)

A couple of decades later I discovered it was the same system the

SWTPC "Dynamic Address Translation" uses. ;)

[Sergey Kiselev]

On Wednesday, September 10, 2025 at 12:08:37 AM UTC-7 Jonathan Harston wrote:

Coming late to this conversation, but this is what i designed for a

mmu for a Z80 40 years ago:

https://mdfs.net/Info/Comp/Z80/Circuits/1MbMem.gif

I designed the I/O such that writing to port Nxxx controlled

the mapping of memory at Nxxx. (ie, OUT (&3xyz),n where xyz is

the decoded paging address controlled the mapping of memory

at &3000-&3FFF.)

Interesting schematic. A few observations:

- Page table readback is a useful feature.

- The 74LS219 (74F219, 74LS189,  74F189) are no longer manufactured, although some of these ICs are available from eBay.

- The MMU uses 16-bit I/O addresses. This limits the applications to Z80. 

- The I/O address decode circuit ignores M1. That will interfere with interrupts.

[Mark T]

Maybe replace the ‘219s with a 32k x 8 15ns ram. 

Anybody want an mmu with 2 byte block size :)

It looks like both RD and WR are used so M1 is not needed.

[Jonathan Harston]

On Wednesday, 10 September 2025 at 15:54:03 UTC+1 Sergey Kiselev wrote:

- The MMU uses 16-bit I/O addresses. This limits the applications to Z80. 

That particular design, yes. Just modify it appropriately.
 

- The I/O address decode circuit ignores M1. That will interfere with interrupts.

I've never used M1 for I/O decoding, always IORQ+RD or IORQ+WR, as
specified by The Manual. Never had any problem with interupts. The
datasheets show nothing that would interfer with interupts.

[Sergey Kiselev]

On Wednesday, September 10, 2025 at 8:10:52 AM UTC-7 Mark T wrote:

Maybe replace the ‘219s with a 32k x 8 15ns ram.  

Anybody want an mmu with 2 byte block size :)

 

You'd need a dual-port RAM... not that these don't exist ;)

 

It looks like both RD and WR are used so M1 is not needed.

Thanks for this clarification.... For some reason I thought that during the interrupt acknowledge cycle, Z80 would activate /M1, /IORQ, and/RD... But apparently it only activates /M1 and /IORQ, so that helps :)

[Sergey Kiselev]

On Wednesday, September 10, 2025 at 10:17:20 AM UTC-7 Sergey Kiselev wrote:

You'd need a dual-port RAM... not that these don't exist ;)

Maybe not a dual-port, but having separate inputs and outputs definitely helps. Although it should be possible to use a couple of tri-state buffers to connect the SRAM data signals to either the CPU data bus, when writing or reading the page table, or to the address bus, during normal operation. Having two separate sets of address lines helps in case the MMU is not located at the same I/O addresses as the memory pages it manages. Again, it should possible to come up with some contraption, e.g., tri-state buffers or multiplexers that would choose what part of address bus goes to the MMU RAM.

[Ed Silky]

Plus, the timing diagram for an I/O RD/WR doesn't include M1- (indicating that it doesn't come into play). If you are buffering the Z80 address and data lines (needed for larger bus sizes) you should use [RD- | M1-] to select 'IN' for the data direction (if INT Mode 2 is going to be used).

-Ed

On Wednesday, September 10, 2025 at 10:17:20 AM UTC-7 Sergey Kiselev wrote:

[Tadeusz Pycio]

 For some reason I thought that during the interrupt acknowledge cycle, Z80 would activate /M1, /IORQ, and/RD... 

Unfortunately, it does not activate the /RD signal, which complicates the glue logic for I/O circuits not designed solely for Z80 support. However, the /M1 signal in combination with /IORQ is required when connecting the /RD and /WR signals directly.

 

[Jonathan Harston]

 
That's exactly what I thought.
gate(IORQ,WR) -> write to device

gate(IORQ,RD) -> read from device

gate(IORQ,M1) -> interupt cycle

I/O access doesn't care and doesn't need to care what the state of M1 is.

[7alken]

thanks Sergey, ya, I had in mind  Z80-512K for sure, you already did a lot ... those smaller pages, its more specific to experiments with vmex, expecting just aligned page sized "tiny cores", spliting any bigger app for smaller (async) modules, so context switch per entire page with reg-file, everything ... primitive, experiments, fusion of something new even with retro technology ... but its all possible even in sw easily using larger pages then, ya ... really considering buy of Z80-512K (but I still dont have even RCBus backbone... just peeked in Stevens shop) , thanks
Petr

[Ed Silky]

Hi Jonathan,

Interesting circuit, as it is nice to be able to read the page registers. That is a must for my project, as I have other things that can take over the bus and they need to be able to read the registers (and the state of the paging enable as well (not shown on yours)), so that they can modify things and then put them back before relinquishing the bus.

However, maybe when you redrew it (as indicated by the text), you didn't get it quite right... Looking at it, it seems like half of the '244 will get enabled any time there is a /RD, regardless of the address or whether it is /MREQ or /IORQ.

-Ed

On Wednesday, September 10, 2025 at 12:08:37 AM UTC-7 Jonathan Harston wrote:

[Mark Pruden]

There is a very interesting thread where the use of 74LS670 4x4 register file is used to create a MMU for a Z80. Its quite a good (but long) read.

https://www.eevblog.com/forum/projects/z80-memory-banking-for-128k-mmu-design/

[Jonathan Harston]

On Friday, 12 September 2025 at 21:51:09 UTC+1 Ed Silky wrote:

However, maybe when you redrew it (as indicated by the text), you didn't get it quite right... Looking at it, it seems like half of the '244 will get enabled any time there is a /RD, regardless of the address or whether it is /MREQ or /IORQ.

I think you're right. I was misled by the '244 being called an "Octal" buffer. It's not,

it's a dual quad buffer. OE1 gates Q0-Q3, OE2 gates Q4-Q7, rather than OE1+OE2

gating *all* of Q0-Q7. Which is what an *octal* buffer would do. I'll see if I can dig

out my original paper notes and see what I originally put together.

[Ed Silky]

Here's my circuit. It includes the ability to read the page registers. On another page is the part that allows you to read the state of the paging enable and whether the page enable has ever been written to.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/7551ad6c-3bd8-46ec-9788-917d73017a48n%40googlegroups.com.

[Ed Silky]

Here is the code to read the page registers.

'''
LD      BC,MEMPGREG ; I/O Address of Page Registers (base, B gets 0)
IN      A,(C)       ; Read Page Reg 0
; Do something with the register value
LD      B,$40
IN      A,(C)       ; Read Page Reg 1
; Do something with the register value
LD      B,$80
IN      A,(C)       ; Read Page Reg 2
; Do something with the register value
LD      B,$C0
IN      A,(C)       ; Read Page Reg 3
; Do something with the register value
'''

-Ed

[Ed Silky]

I realized that it might be helpful to see the decoding logic.

And the part that makes the page enable and written available.

-Ed

[Jonathan Harston]

On Saturday, 13 September 2025 at 17:33:49 UTC+1 Jonathan Harston wrote:

I think you're right. I was misled by the '244 being called an "Octal" buffer. It's not,

it's a dual quad buffer. OE1 gates Q0-Q3, OE2 gates Q4-Q7, rather than OE1+OE2

gating *all* of Q0-Q7. Which is what an *octal* buffer would do. I'll see if I can dig

out my original paper notes and see what I originally put together.

From a quick skim through a 74series index, I think it should be a '245 not a '244.

[Ed Silky]

'245 is bidirectional. It contains a single enable, plus a direction. Your circuit doesn't need the bidirectional capability; you just need to do a little more on the enable condition logic and use it on both enables on the '244.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/8dc18f28-25b1-4762-ba2e-d0ebbae8454bn%40googlegroups.com.

[Mark T]

Don’t leave inputs on the ‘138 floating.

[7alken]

hi Ed and Jonathan, nice ... and I noticed you Ed are planning to use DIP32(?) AS6C4008 ... as I am just now working here on SRAM minimodule extending slightly DIP32 footprint
by adding 100mil/2.54mm below another line of precision females (checked all available RCBus memory modules that it can fit physically, ignoring bottom 16pins - may be  pull them
required...ya) for possibly 16bit/2byte memories and extending addresses too - are you okay to leave there such space?? )) ... and pls, if you can comment this pinout? ... I tried to have
data out of mostly fast switching addresses, hopes that upper address lines wll not be also so fast for EMI? am I missing something? - reason for this is I want to test some faster SRAMs also elsewhere and to reuse such adapters for tssop/bga (with added 74138 optionally or so) - also as "ZIF" testing for such tiny chips with some crazy techniques... any such module
then can be inserted into DIP32 and work at least as 512k (but faster, down to 10ns or so ??) ... is this totally stupid or may it have some wider backing??
thanks, Petr

[Jonathan Harston]

I found my original notes, and yes it was a '245:
https://mdfs.net/Info/Comp/Z80/Circuits/1MbMMUv0.gif

Something went wrong when rotating the diagram to tidy it up. ;)

[Ed Silky]

Hi Mark,

Yes, I don't leave any inputs floating. That screenshot was in-progress.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/7a7c3914-c4b0-4c86-9a16-12ccabeafbbfn%40googlegroups.com.

[Ed Silky]

Hi Jonathan,

Very good.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/0fac03ff-f7c2-48d4-9dda-ed14d1001279n%40googlegroups.com.

[Ed Silky]

Hi Petr,

Yes, I have 32 PDIP for both the RAM and ROM. I am using DIP/through-hole for everything on this board, so that it looks more the part. I work almost exclusively with surface mount for my robotics projects, and I'm building a front panel for this board that will be surface mount, but I don't plan on that board being visible. This board will function with or without the front panel, but the front panel will provide a number of peripherals (wifi, SD cards, RTC, HDMI, keyboard) and the ability to load and manipulate the memory and I/O using a keypad and 7-seg LED display, and to program the ROM. Because of the ability for the front panel to take over the bus and update memory and program the ROM, I needed the ability to read the segment registers. That allows the front panel to read them, change them, make memory changes, and then put the segments back as they were, before releasing the bus back to the Z80.

For your module/adaptor, do you have some memory components in mind? I haven't done a lot of searching, but in a 5V part, I don't find many that are larger than 2Mx8/1Mx16, so 20 address lines covers those. Those are in a TSOP-48 package. They have a negative and a positive chip enable, so you might want to include an option to have an inverter for the second enable, or maybe you could include some on-module decoding?

-Ed

On Sun, Sep 14, 2025 at 11:48 PM 7alken <antos...@gmail.com> wrote:

hi Ed and Jonathan, nice ... pls, I noticed you plan to use AS6C4008 (dip32?) ... I now used some weird word (against me) not sure it post was erased because of this, so paragraph will be shorter ... I plan some adapter for DIP32 socket for larger and faster memories in smd (still quite retro, though) so, I here just drafted how to extend DIP32 to DIP32+16, as original idea of DIP40+20 is not necessary (although even this can fit into all RCBus memory board I found) - it has planned usage for testing even using simple burn-test ZIF methods or just to insert such module anywhere where DIP32 socket is ... is this weird or may it have some wider backing ??

thanks, Petr

On Sunday, September 14, 2025 at 12:43:22 AM UTC+2 Ed Silky wrote:

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/ca5a51da-598e-42a1-b928-ed053246a6acn%40googlegroups.com.

[7alken]

hi Ed, interesting project :-) - ya, for module I plan here many at 3V3 (obsessed with 3V3, excuse me) but found some exists in 5V too, to fit more of them even on this tiny adapter together with 74138, that's the plan; but this DIP32+16 is only temporary/testing mid-solution for 7xmod which is 51x51 max havind DDR2 sodimm (large part only) 80pins (single sided conn + added bottom grounds) or 2x40pin 1.27mm (double sided conn), inserted/soldered on 1mm PCB (BillShen does this way his (temporary) CF connection around 2mm 44pin, where it just fits on 1.5mm PCB)

it is about possibility to reuse anything possible (found anywhere deep in stocks) even with decoder, with unified defined interfaces, here is something below 20ns 5V on mouser
https://cz.mouser.com/c/semiconductors/memory-ics/sram/?access%20time=10%20ns~~20%20ns&interface%20type=Parallel&mounting%20style=SMD%2FSMT&organization=64%20k%20x%2016~~1%20M%20x%2016&supply%20voltage%20-%20max=5.25%20V~~5.5%20V&instock=y&rp=semiconductors%2Fmemory-ics%2Fsram%7C~Supply%20Voltage%20-%20Max%7C~Access%20Time%7C~Organization&sort=pricing

but my primary goal now is to lay on this module my FlexZIF - aka "flex micro-tht grid with 'soft rubber' support" for bga48/90 momentarily testing; it is just for easy/cheaper experiments with any older "waste(?)" possible in the wild )) ... I was also asking if you have now that extra space below DIP32 to lay the extra pins there (addr lines must have on module pullups, ya?)

Petr

[Ed Silky]

Hi Petr,

Here is a 5V part on DigiKey: https://www.digikey.com/en/products/detail/infineon-technologies/CY62167ELL-45ZXI/1644404

It is 1Mx16 or 2Mx8, and is an active, stocked, part. That's about as large as I've found for a 5V part.

The extra row of pins wouldn't be a problem, but you'll find that getting the part in and out will be quite a bit harder. Kind of like getting a pin-grid part out.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/8730e393-afd7-4236-8efb-486593226700n%40googlegroups.com.