Z80 MMU (Zeta)

[Tadeusz Pycio]

Another processor module design with MMU, this time based on a well known and used Sergey concept. I decided to move the MMU into the processor module to make use of the available memory for the Z180/280, which really should be where the MMU is. I'll admit that the project came about for my convenience, as I got bored of using the ROM emulation plugin for Z80-based systems (I have a dedicated module that replaces that for me). I think I will opt for a PCB design this time.

[Sergey Kiselev]

Looks good. I like the idea of using multiplexers to switch higher address lines for MMU disabled vs. MMU enabled cases.

[Tadeusz Pycio]

Looks good. I like the idea of using multiplexers to switch higher address lines for MMU disabled vs. MMU enabled cases.

Hi Sergey,
Too much choice I didn't have, what works successfully on the SBC or on the internal memory module bus, when used as a standalone MMU seems to be the only option. This extends your concept somewhat, but retains the idea.
I'll be starting design work soon, as I'm currently delving into another topic I've been looking for for a very long time - a modern microcontroller that operates at 5V. As I manage to master it to a minimal degree, I will share the information in another thread. I'm talking about the CH32V103C8T6, it's not retro, but from a tool to make retro systems easier to run, it doesn't have to meet those criteria.

[Douglas Miller]

Looks very similar to a 512K RAM MMU I did for Heathkit computers. Except I put two sets of map registers, one for read and one for write. That allows CP/M 3 (and ramdisks) to do more efficient transfers, at the cost of needing to update more map registers when changing "banks".

[Tadeusz Pycio]

After a delay of more than a year, I have returned to this project and it looks like I will be completing it soon. The schematic has been simplified a bit and I think it should work.

[Tadeusz Pycio]

Revised scheme, the previous one had unusual addressing in relation to the available Zeta2-compatible MMU-based modules in the RCBus environment.

[Mark T]

Is it worth including MREQ in the control of the ‘257 to still support 16 bit i/o addressing?

Maybe a switch from ‘257 to ‘253 as only two outputs of the ‘257 are used.

[Tadeusz Pycio]

Hi Mark,

It's a good idea, looks like it won't require adding more ICs if you change ‘257 to ’253. This design required some tricks to get a NOT gate from the available one free flip-flop anyway. However, the simplification involves incomplete I/O decoding. Although I don't know if anyone uses 16-bit I/O addressing in an RCBus environment.

[Mark T]

Its not common to use16 bit i/o addresses. I think Alan Cox has a few modules that support this, but not sure if anyone else is using them. 

[Mark T]

I was wondering about the reason for using the ‘74 for BUSEN, I thought maybe you wanted a slight delay.

An asynchronous method of using ‘74 as inverter is to ground the clear input and use the preset input and Q output.

[Bill Shen]

 My VGARC uses 4K of the 16-bit IO space to map every screen character position to an IO location as well as font tables for 128 characters.  VGARC uses the classic 40-pin RC2014 connector.

Bill

[Tadeusz Pycio]

An asynchronous method of using ‘74 as inverter is to ground the clear input and use the preset input and Q output.

Yes, you are right. I know I considered both options and I can't remember why I thought this was the best solution a year ago, perhaps it was due to the convenience of running the paths. The current distribution of elements leads me to return to the asynchronous solution. Thank you for bringing this to my attention.

I checked the availability of 74HCT253 chips - it doesn't look good, I think I'll stick with 74HCT257 and the resulting consequences.

[Tadeusz Pycio]

Two versions have been created, both with a PCB design. I don't know yet which one I will send to production, everything will depend on the availability of mutiplexers. The 74HCT257 ICs are readily available, with the 74HCT253 there is a problem.

@Mark - Thanks for the feedback, as I would probably leave the synchronous version of the NOT gate despite moving the clock source to the left side of the PCB (I didn't pay attention to that - I avoid using vias for clock and power signals in my designs).

[Mark T]

I was thinking the ‘74 could be changed to ‘00 and use a set-reset latch for MEN. It loses the ability to disable the MMU after it has been enabled, I don’t think that is needed for ROMWBW. This gives you one gate for the inverter and one spare that could be used to combine MREQ and MEN to stay with the ‘157.

A ‘157 might be able to act as latch and address line selector, select input via one of the unused outputs, but then you would need additional chip to tristate the outputs and might need an inverter to reset the latch. Tristate would not be needed if the mmu is direct to the memory so I might explore that for a minimum sbc.

[Tadeusz Pycio]

With the usual delay for me, the CPU module with Z2 MMU is now ready. :)

[Sergey Kiselev]

Hi Tadeusz,

Have you ever shared your Z2 MMU project on GitHub?

Thanks,
Sergey

[Tadeusz Pycio]

Hi Sergey,

Oops, I actually did not make this project available on GitHub contenting myself with just a mention on my website. I will try to rectify this as soon as possible. The ZBUS modular computer project (Z8000, Z280) is consuming most of the, currently quite limited time, I can devote to my hobby. In good news, I should soon have modules ready for the XR88C681 ( and derivatives ) in RCBus format, which I mentioned in another thread.

[Jaap van Ganswijk]

Why are you still using a bus-system design? Just put all the chips on a single  board and design a new one every several years. And use a Z180 or better and you won't need two NS74LS670's as an MMU. In my TRS80 days I also expanded it with a bus system, but that is outdated now.

But have fun! ;-)

On Thu, 22 May 2025, 20:45 Tadeusz Pycio, <ta...@wp.pl> wrote:

Hi Sergey,

Oops, I actually did not make this project available on GitHub contenting myself with just a mention on my website. I will try to rectify this as soon as possible. The ZBUS modular computer project (Z8000, Z280) is consuming most of the, currently quite limited time, I can devote to my hobby. In good news, I should soon have modules ready for the XR88C681 ( and derivatives ) in RCBus format, which I mentioned in another thread.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/59653e2a-babe-4519-b5bb-25eae3fad638n%40googlegroups.com.

[Tadeusz Pycio]

This is a good question, but I think I have the answer. The phenomenon of RC2014/RCBus is that it is a system with elementary modules so that you can configure your computer as you like, unlike S100 or N8VEM which use more complex modules so that you lose that flexibility. Probably not everyone likes this concept of building a computer and prefers monolithic solutions that easily allow them to be enclosed in a nice case and allow them to focus on the software. I used to build such systems in the past, but they never met my expectations, because I always came to the conclusion after some time that I could have done something differently, there were often some elements missing that doomed the whole project. With RCBus I don't have such problems, I change the modules accordingly to achieve the desired goal. The modular system also has a huge advantage, because when I'm working on a new module, I focus only on it, the rest of the computer is already comprehensively tested, and the unification of the bus ensures compatibility between them. Yes, there are disadvantages to this solution, it is difficult to enclose such a system in an enclosure and there are also higher construction costs, for the PCB factory it does not matter whether they produce an SBC or a single module, the price is similar and in the case of a modular computer you need at least 3-4 such PCBs.

[Ronny Ribeiro]

Beautiful!

Em sex., 17 de jan. de 2025, 16:57, Tadeusz Pycio <ta...@wp.pl> escreveu:

With the usual delay for me, the CPU module with Z2 MMU is now ready. :)

--

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

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/fe8283d2-c2cd-434f-943a-26c456dc6028n%40googlegroups.com.

[7alken]

it is :-)

[Tadeusz Pycio]

The project has been made available on GitHub.

[7alken]

Thanks Tadeusz - please, there was also some discussion about 16bit IO addressing, yes or no ... ?? (affects Bill VGARC); what was resolution of this debate?
or, why that debate was needed in fact? is he using some tricks?
Petr

[Bill Shen]

 

It is standard Z80 IO operation to put contents of reg B on address bus A[15..8] and reg C on A[7..0] with instruction OUT (C),A.  So Z80 has 16-bit IO space all along.

Bill

[Mark T]

Another interesting one is that IN A,(nn) puts the current value from A onto A15-8 and reads D7-0 into A in the same cycle. I was going to try and use this to shift bits in and out of A but still not got around to trying it yet.

[7alken]

thanks for clarifying; I probably thought that this out (c),a was new thing on Z180 - this seems like possible to simulate for other intel 8bits as 8085 by adding single 8bit latch?
at least at hardware level, using 2 outs ?? you know, I started thinking about generic MMUs (and more debate now in retro-z80)
ya, all means more chips and less physical space available... debate about "full" 8bit ioports are was also interesting; something can be probably done by serializing sequence of

writes to single out-only port, but again, far more logic ... grrr; these CPLDs were part of old machines very soon, also Ferranti ULA, all the custom chips in home computers...
(cant imagine today how they were done, if as some form of generic chips as ULA, or as totally custom ASICs?? -- seems extremely expensive, even today ...)

Petr

[Alan Cox]

On Mon, 26 May 2025 at 15:24, 7alken <antos...@gmail.com> wrote:

thanks for clarifying; I probably thought that this out (c),a was new thing on Z180 - this seems like possible to simulate for other intel 8bits as 8085 by adding single 8bit latch?

8080/8085 output the same byte on both halves of the bus, and there were early S100 machines relying on this so some Z80 boards even had jumpers to fake the effect. It is doable with latches but you need to mux the address bus between the latch and CPU if you do so, Not hard if you use a 574 and mux it with A8-A15 based on IORQ.

 
(cant imagine today how they were done, if as some form of generic chips as ULA, or as totally custom ASICs?? -- seems extremely expensive, even today ...)

ULA was a custom metal layer over the gates as I understand it - fine for high volumes. If you look at some of the 1982 machines and cards though others were using early PLDs, and even before that it was common to use tiny PROMs for stuff like address decoding.

[7alken]

thanks again to all Bill, Alan, Mark ... ya, that 80C85 is interesting, I have here some OKI qfp/plcc (that oki really pushed to 3V3 cmos, more than toshiba), I re-read again feilipu and Alans designs, I was wondering how these 16-bits IO on them, want to build some existing RCBus/RC2014 system, not sure which one yet; around Z180 I had that very wild radio transmitting breadboard (nice it lead up to Bills 64MHz at 3V3 here, haha); ya, Ferranti ULA history has some interesting video on youtube, with all the quite ugly details )); ...aha, that PROMs, ya, true,
btw, I remember at high-school 85-89, our local Tesla Piestany was selling still MHB8748/8048 here, I was trying to abuse the signals to be able to write even to external program SRAM (that 4kB, in fact 2x 2kB), with serial uart bit-bang boot from 74188, I had written that 32byte code (simulated in head only), it was SBC of size of that Welsh Altoids, but only drawing, not realized - at that time I even went to local patent office to investigate if that "writing to program SRAM by data instructions" can be protected (very naive funny experience, NEVER more) ... but I absolutely don't remember what I had found there on the signals charts, probably nothing so miraculous, of course ... but there was interesting that 4bit semi-serial expander 8243; knowing today it was already 10+ years old and in fact one of first MCU, it might be 3 chips, single 5V tiny system ... but then came "velvet" here, and PC; )) ... btw, in relation to 8048 its interesting that CHM has NOT published oral history video, although the transcript IS available ... because, one of my recent weeks action was "re-mastering" of audio of 68000 oral history panel (I dont want to touch history record from 2007. but I was trying to listen these good guys several times, but the first 30 minutes are drown in noise/hum/hiss very badly, so I have already done here at 90% complete cleaning, noise spectrum subtracting, manually/carefully, wanting to absolutely preserve the true voices, without any automatic dynamic processing, afraid,  but another 10% will be next equally long pass to correct Tom's voice dynamics (RIP) - at least I already heard this cleaned and everything mentioned around first 68000 is very interesting, and entire track is louder to the end as guys are laughing more and more...), will send the clean audio track to CHM if they are interested, I don't know ... but that missing 8048 oral history video is interesting also :-( ... well, excuse me pls again mixture of brain unload;
Petr

[Stefan V. Pantazi]

Hi Tadeusz,

Thank you for making this Z2 MMU available. I built it and tried to see if it worked with a SC721 512k RAM+ 512k ROM  memory module and a SC132 (SIO/0) but with no luck so far to run RomWBW. SC721 is tested and configured with RAM low and ROM high.  Maybe I am missing something obvious. I would appreciate any suggestions.

Stefan

[Stefan V. Pantazi]

I misspoke, my SC721 was configured normally with ROM low and RAM high so Z80 can find the ROM at boot.

The Z2 MMU module did show a sign of life once (boot but with garbage on serial) with some older RomWBW 3.5 firmware but I have not been able to make it work at all with RomWBW 3.6.

I suspected Z2 MMU (74670) registers initialization was missing from older RomWBW and hoped the newer version added Z2 MMU initialization.

My testing is in minimal configurations with MMU/CPU cards, SC721 and SIO. 

So far no luck.

[Wayne Warthen]

Hi Stefan,

I have not tried this hardware configuration.  I don't have the specific boards.  However, it seems like it should work.

One question.  What are you using for the bus?  The standard RC2014 bus does not connect the A16-A19 address lines which would be required for your scenario.

Thanks, Wayne

[Stefan V. Pantazi]

Hi Wayne, 

Thank you for the quick reply. I am using the full RCBus (80 pins). After some additional investigations it looks to me that with this version of the CPU - MMU board the 74LS670 are not tri-stated (the Read Enable pins is tied to GND) and the values of addresses A16, A17, A18 and A19 are all 1 at boot (despite the 10k pull downs), which makes the CPU not find the startup portion at the ROM. I guess it may be possible that an initialization routine placed at the beginning of the last 64k page of the ROM may fix it but this is just a hunch.

Thank you again for the help.

Stefan

[Wayne Warthen]

Ah, OK.  That would explain it.

-Wayne

[Tadeusz Pycio]

Hi Stefan,
RomWBW has supported this configuration for a long time; I adapted the hardware for convenience, to ensure it was compatible with existing solutions. So you don’t need to look for solutions in the latest versions.

I would focus instead on explaining why, after a reset, lines A16–19 are high (changing the ROM to the upper section won’t help in this case). I haven’t tested this module with chips manufactured using LS technology, so for this type I would halve the resistance of the pull-down circuit – to 4.7 kΩ. The 74LS670 chips have tri-state outputs. 

What was the transmission error during the successful start-up attempt?

 

PS. Sorry for the delay, but I’ve been on a trip away from civilisation (the beauty of the mountains and forests…).

[Stefan V. Pantazi]

Hi Tadeusz,.

No worries, thank you for the timely reply! 

The successful startup attempt may have been a fluke during my many attempts to swap various modules including a SC730 to test the setup. I did try various combinations of SC721 (ROM+RAM), SC132 SIO/0, SC719 digital IO 98 (for debug LEDs) and occasionally a KIO and VRC RC2014 modules which I enabled in RomWBW. Somehow there was a successful boot with your Z2 MMU card which I have not been able to replicate since with RomWBW 3.6. Possibly the pair of  74LS670 got initialized and stayed on 0 in between the tests. My understanding is that at powerup the 670 registers are in an unknown state. Logic 1 at powerup could be specific to LS670 but I cannot compare as I do not have HCT670. Of course, initialization can take care of the registers, provided CPU can find some initialization code in ROM. In a case where A16-A19 are all 1,  this code would need to be really high up in the memory space. This would be the "software" solution which I attempt as soon as I finish learning about the structure of RomWBW ROM disks.

I can confirm that the CPU is "alive" as demonstrated by the address and data bus lines activity, probably executing whatever it finds in memory. I can also confidently confirm (after taking the CPU and the oscillator module out) that the initial, powerup state of the LS670's seems to be logic 1 consistently and that all A16-A19 address lines are high explaining the boot problems. On the Z2 MMU card Pins 11 (read enable, active low) of both LS670 are tied to GND which effectively turns their outputs on. Without having their output tri-stated, the 10k pull downs have no effect on the LS670 outputs which remain high. On the ROM+RAM SC721 card there is an optional pull-up which is installed and I thought I may need to take out but it is a weak 100k so it should not matter. Indeed it does not, A16-A19 remain high even after taking SC721 completely out of the system.

The more complicated hardware+software solution I am contemplating may be to reuse the half of the flip-flop that is currently used to get /BUSEN from  /BUSACK and tie /BUSEN to GND, as I do not have anything yet in my systems that uses DMA. Then in the software and extra OUT instruction to enable LS670 outputs during boot. Or would could using one of the already existent /MON or /MEN signals achieve a similar effect (i.e., controlling the output of LS760)?

Stefan

[Stefan V. Pantazi]

Update on some progress.  I disconnected pin 11 (read enable, active low) of both LS670 from GND and connected them to /MEN (pin 6 of U5A that controls the switching in U3 (LS257) which is on logic 1 at reset (/Q output of U5A flip flop). As a result A16-A19 stay low at boot as they should, ROM is found in first 16k, booting starts and I get LED 0 of the IO board to light up. As the configuration I use is RomWBW for a machine with MEMMGR == MM_Z2 (I may need to double check that) I was hoping that this bit:

LD A,1
EZ80_IO()
OUT (MPGENA),A ; ENABLE MMU NOW

will take care of things, enabling the LS670 outputs and making MMU work. Something still not right though, unsure what yet. 

I came across this comment in the code:

 " #IFDEF ROMBOOT

; IF THIS IS A ROM BOOT, SETUP THE FIRST 2 16K MMU REGISTERS
; TO MAP THE LOWEST 32K OF PHYSICAL ROM TO THE LOW 32K OF
; CPU ADDRESS SPACE (BANKING AREA).  THE FIRST 16K MAPPING IS
; REDUNDANT BECAUSE WE ARE ALREADY RUNNING IN THIS AREA.  THE
; MAPPING OF THE SECOND 16K IS CRITICAL BECAUSE ALL ZETA 2
; MMU REGISTERS WILL BE 0 AT RESET!

"

I think it would be more appropriate for last line to read:

; MMU REGISTERS WILL BE UNDEFINED AT RESET!

[Wayne Warthen]

On Wednesday, April 15, 2026 at 5:06:31 PM UTC-7 Stefan V. Pantazi wrote:

I came across this comment in the code:

 " #IFDEF ROMBOOT

; IF THIS IS A ROM BOOT, SETUP THE FIRST 2 16K MMU REGISTERS
; TO MAP THE LOWEST 32K OF PHYSICAL ROM TO THE LOW 32K OF
; CPU ADDRESS SPACE (BANKING AREA).  THE FIRST 16K MAPPING IS
; REDUNDANT BECAUSE WE ARE ALREADY RUNNING IN THIS AREA.  THE
; MAPPING OF THE SECOND 16K IS CRITICAL BECAUSE ALL ZETA 2
; MMU REGISTERS WILL BE 0 AT RESET!

"

I think it would be more appropriate for last line to read:

; MMU REGISTERS WILL BE UNDEFINED AT RESET!

Yes, you are right.  In fact, there are multiple issues with this comment.  I will correct it.

Thanks, Wayne 

[Stefan V. Pantazi]

On second thought, it does depends on the actual implementation of the MMU. if the registers (like 273) have a master reset pin tied to reset, then the statement about register being 0 at boot is actually correct.

I have a progress update, there was a wiring error which prevented the MMU to be enabled, now all boot steps do complete (all 8 status LEDs ON)  most of the time, there is serial activity, however the there are still problems with the MMU, ending in boot getting stuck or in a boot loop. Maybe the solution to tie LS670 read enable to /MEN is not quite right, or there are timing issues I have yet to figure out. 

//here is a subset of the repeating console messages at boot

RomWBW HBIOS v3.6.0, 2026-04-15

RCBus [RCZ80_z2_mmu_test_cust] Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, Z2 MMU
512KB ROM, 512KB RAM, HEAP=0x40D1
ROM VERIFY: 00 00 00 00 PASS

LCD: IO=0xDA NOT PRESENT
SN76489: LEFT IO=0xFF, RIGHT IO=0xFB

RomWBW HBIOS v3.6.0, 2026-04-15

RCBus [RCZ80_z2_mmu_test_cust] Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, Z2 MMU
512KB ROM, 512KB RAM, HEAP=0x40D1
ROM VERIFY: 00 00 00 00 PASS

LCD: IO=0xDA NOT PRESENT
SN76489: LEFT IO=0xFF, RIGHT IO=0xFB

RomWBW HBIOS v3.6.0, 2026-04-15

RCBus [RCZ80_z2_mmu_test_cust] Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, Z2 MMU
512KB ROM, 512KB RAM, HEAP=0x40D1
ROM VERIFY: 00 00 00 00 PASS

LCD: IO=0xDA NOT PRESENT
SN76489: LEFT IO=0xFF, RIGHT IO=0xFB

RomWBW HBIOS v3.6.0, 2026-04-15

RCBus [RCZ80_z2_mmu_test_cust] Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, Z2 MMU
512KB ROM, 512KB RAM, HEAP=0x40D1
ROM VERIFY: 00 00 00 00 PASS

LCD: IO=0xDA NOT PRESENT
SN76489: LEFT IO=0xFF, RIGHT IO=0xFB
SIO0: IO=0x80 8440 MODE=115200,8,N,1
SIO1: IO=0x82 8440 MODE=115200,8,N,1
MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
CH0: IO=0x3E NOT PRESENT
CH1: IO=0x3C NOT PRESENT
FP: IO=0x00 SWITCHES=0x00

RomWBW HBIOS v3.6.0, 2026-04-15

RCBus [RCZ80_z2_mmu_test_cust] Z80 @ 7.372MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, Z2 MMU
512KB ROM, 512KB RAM, HEAP=0x40D1
ROM VERIFY: 00 00 00 00 PASS

LCD: IO=0xDA NOT PRESENT
SN76489: LEFT IO=0xFF, RIGHT IO=0xFB
SIO0: IO=0x80 8440 MODE=115200,8,N,1
SIO1: IO=0x82 8440 MODE=115200,8,N,1
MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
CH0: IO=0x3E NOT PRESENT
CH1: IO=0x3C NOT PRESENT
FP: IO=0x00 NOT PRESENT

-----------------------------------------------------

[Wayne Warthen]

It looks like the system is restarting when the first interrupt fires.  I don’t see anything that should be firing an interrupt during boot though.  Might be worth building a ROM with interrupts disabled.  INTMODE 0

-Wayne

[Stefan V. Pantazi]

Your suggestion to disable interrupts absolutely fixed the boot looping. I also disabled the LCD and CHx devices and kept the minimum. 

I noticed I had the TMS9918 interrupts enabled as well but the device itself was not enabled. I disabled those but I am unsure if that made any difference.

The machine appears stable and runs the usual programs without any problems. I attached a short log.

I will attempt to enable INTMODE 1 to see if the boot looping behaviour reappears.

Thank you for the help!

[Wayne Warthen]

Looks great.

I have seen an uninitialized TMS9918 generate interrupts.  So, either disable them on the TMS9918 module or be sure to enable support for the device in your ROM.

Thanks, Wayne

[Stefan V. Pantazi]

Just to clarify, I did not have TMS9918 hardware present in the system, I disabled the device in configuration but left its interrupts and 80 character mode enabled. Still unsure if these had any impact.

I just did another experiment and reenabled INTMODE 1. All seems OK (I attached another short log), so it must have been a different cause responsible for the boot looping and instability. I cannot completely exclude the precariousness of my temporary hardware modification done with wire clips and extra sockets. Anyway, I am fairly happy to have a hardware-only solution to the Z2 MMU with LS670 boot problem. 

Thank you again for the help!

[Tadeusz Pycio]

Hi Stefan,

Now I understand why you began to suspect that the 74LS670 chip doesn’t have tri-state outputs... this is because, unfortunately, I uploaded a provisional version of this module to GitHub – a physical prototype had even been built for it – but it simply wouldn’t work, not even with HCT chips. I’m sorry that you created this module based on my mistake, and I must admit that I don’t know how this interim model came to be available. Today I’ll try to send the correct files along with the second version for 253, which I didn’t include. I don’t know what went wrong, why commit the correct version didn’t work. 

This is what the correct versions of these modules should look like (I’m not sure what to do about the numbering of the first one now).

[Stefan Pantazi]

Hi Tadeuzs, I see that the only differences with model A are the 670 read enable connected to /MEN as I figured, It was a good exercise to go through and I am glad I managed to solve it before you had a chance to help. 

Thank you for making the boards available and for updating the git repository!

Stefan