Things only become obsolete when we stop using them.

Some industries always find ways for their customers to “need” the newest version of whatever they make, even if the previous versions are still in working condition.

It looks like not so long ago, some of our devices did last longer though…

The French touch.

There’s a very French device launched in the early 80s, for which the services were maintained up until 2012 : the Minitel. There was close to nothing one could do with this small terminal until it was plugged to a landline.

Models known as the M1B and M2 had a DIN5 port of the back carrying a 5V TTL UART though. The little terminal found various alternative uses and over the past few years, these have been used as Linux/Arduino/Raspberry Pi terminals.

Limiting modern microcontrollers/modules because of a 4800 Baud rate with the M1B version, and 9600 Baud rate with the M2, doesn’t feel that interesting though.

There are more exciting projects, like this one that makes use of the original M2 hardware to run custom code, with a focus on the video capabilities, or this other one for which a daugtherboard was made for the M1B.

Since the most common/easy to find version of the Minitel with a serial port seems to be the M1B, let’s focus on this version and have a look at its architecture.

Intel inside!

At the heart of the M1B is the Intel 8052 microcontroller, which has 8KB of internal ROM, 256B of internal RAM, 3 x 16-bit timers, 6 interrupts, and runs at 11.059MHz.

The 250000 first units in the Alcatel M1B series apparently came with a 8032 (a ROM-less version), which is one of the reasons why the M1B has an expansion port to connect to a daughterboard. The 8052 is also able to access up to 128KB of external memory (64KB ROM / 64KB RAM) when the External Access enable pin is low.

The daughterboard includes a 8KB EPROM (with plans to access up to 16KB) with a 74LS373 latch and a 74LS244 buffer, the latter being used to read back the keyboard.

Compared to the documentation available online, it appears that on the daughterboard used for experiments, the keyboard is enabled via A14 (vs A9 in the doc/schematic) and the EF9345 semi-graphic display processor is enabled via A15 (vs A8).

The EF9345 display processor has its own memory interface, and can access up to 16KB of RAM. It also has its own crystal and is clocked at 12MHz. The M1B is fitted with 8KB of video RAM which can be increased to 16KB via an expansion connector. In the M1B, the display processor also controls a piezo buzzer via a pin that can be used as a GPO.

The keyboard makes use of 3 GPIOs from the 8052 (P1.0~P1.2). These go to a 74LS156 used as a 3-to-8 line decoder for the X side of the keyboard matrix. The Y side is connected to P0.0~P0.7 of the 8052 via the 74LS244 on the daughterboard.

On a unit that is not equipped with a daughterboard, some shunts are populated in order to replicate some connections that would otherwise be made on the daughterboard.

On the schematic, P3.2 is part of a 4 signals bus that goes to the 74LS156. On the mainboard, these 4 signals also go to an unpopulated DIP8 footprint labeled M16. There only is a vague note about these 4 signals in the documentation.

Based on the destinations of these signals on this footprint, it looks like it was planned to use a serial EEPROM like a 93C46, for which the 8052 pins would be used as follows :

  • P1.0 : Serial Data Input
  • P1.1 : Serial Clock
  • P1.2 : Serial Data Output
  • P3.2 : Chip Select

Since the M2 version used an I2C EEPROM to store the user’s contacts and/or a password, an attempt at adding one in the M1B version would make sense.

The MODEM makes use of 6 GPIOs on the 8052 (P1.3~P1.6, P3.3, P3.5).

The serial port makes use of 4 GPIOs from the 8052 (P1.7, P3.0, P3.1, P3.4).

What now?

So we have a quite complete self-contained system, with a screen, a keyboard, a serial port, as well as a MODEM, a piezo buzzer, and a couple of GPIOs, which makes it look pretty close to a home computer from the 80s!

With a 8052 at its core, a display processor limited to a maximum of 25 rows of 80 characters and a monochrome 9″ CRT screen, it sure would look limited by today’s standards.

Since the initial idea is to use the original hardware as much as possible, let’s make something useful, taking into account those limitations.

In order to make the most out of what we have, let’s see what to keep and/or change first.

Room for improvement (rough ideas).

There’s no plan on using the MODEM. The pins from the 8052 used for this part of the circuit should be disconnected to possibly be reused as GPIOs.

Even though there might be obvious reasons for this (reduced cost, closed system), the original memory map seems to waste a lot of possibly usable space because of the way the keyboard and display processor are addressed.

The address “decoding” for these being performed on the daughterboard, some changes could be made in order to optimize the memory map and keep space for additional peripherals.

It should also be possible to free the GPIOs used for the 3-to-8 line decoder and have the keyboard memory mapped on e.g. A8~A10.

Freeing as many GPIOs as possible would mean additional hardware or expansions could be added.

Since the existing daughterboard only addresses ROM, a new one would have to be designed, in order to include Flash ROM and RAM both limited to 32KB of addressable space.

By doing so, it should be possible to trick the 8052 in order to (ultimately) implement some IAP mechanism, to make things more convenient when it comes to updating the firmware.

Since the 8052 would only allow reading from the ROM whereas both reading and writing would be allowed from/to the RAM, it should be possible to let the 8052 actually write into the Flash when it’s supposed to access the upper 32KB of RAM.

This way there could also be some kind of partitioning that wouldn’t allow writing to specific areas in the Flash, in order to dedicate that space to a bootloader and other common routines.

Let’s explore ideas about what to actually do out of it, define the modifications needed, and architecture of the daughterboard more in details in a future post!

Leave a comment

Your email address will not be published. Required fields are marked *