Information wants to be free...

CentreCOM MR820TR Hub Repair

I found a broken "Allied Telesyn CentreCOM MR820TR" network hub in the trash:

MR820TR Broken

When power was applied the power LED would just blink rapidly. The internal PSU is supposed to supply +5V and +12V on two rails, but when I measured these with the logic board connected they were just +1.6V and +8.1V. Disconnecting the logic board showed +4.8V on the +5V rail and variying voltage between +7.3V and +7.6V on the +12V rail, so likely something wrong with the internal PSU.

I measured the ESR of several electrolytic capacitors in-circuit and one of them (C06) in the center of the board had bad readings. I unsoldered this one and measured it again, and it was still bad:

MR820TR Bad Capacitor

I replaced it with a new one:

MR820TR New Capacitor

This network hub is now working again:

MR820TR Fixed

Topic: Repair, by Kjetil @ 05/08-2022, Article Link

Renesas GCC Toolchains Update

I recently installed Slackware 15.0 on a computer and I noticed that my older script no longer works well. Here is an updated script that compiles GCC version 12 and it's associated tools. The steps are also simplified, mainly because "--enable-maintainer-mode" has been removed when configuring "binutils".

I have tested with the two Renesas target architectures that I use; RX and RL78 so one of these can be selected as the argument for the script. By default the toolchains are installed at /opt/ but this can be changed with the PREFIX variable in the script. Also note that "make" as been set up to run 32 parallel jobs which greatly improves the compilation time if you have enough cores, so adjust this as needed.

Here is the updated script:

set -e

if [ -z "$1" ]; then
  echo "Choose a target:"
  echo "1) rx-elf"
  echo "2) rl78-elf"
  exit 0
elif [ "$1" -eq 1 ]; then
elif [ "$1" -eq 2 ]; then
  echo "Unknown target!"
  exit 1


export PATH="${PREFIX}bin:$PATH"

# 1) Prepare build directories:
if [ -d "${BUILD_DIR}" ]; then
  echo "Old build directory detected, please remove it."
  exit 1
  mkdir -p "${BUILD_DIR}/binutils"
  mkdir -p "${BUILD_DIR}/gcc"
  mkdir -p "${BUILD_DIR}/gdb"
  mkdir -p "${BUILD_DIR}/newlib"

# 2) Get sources:
if [ ! -d source ]; then
  mkdir source
  cd source
  wget ""
  wget ""
  wget ""
  wget ""
  tar -xvJf gcc-12.1.0.tar.xz
  tar -xvJf gdb-12.1.tar.xz
  tar -xvJf binutils-2.38.tar.xz
  tar -xvzf newlib-4.1.0.tar.gz
  cd ..

# 3) Build binutils:
cd "${BUILD_DIR}"
cd binutils
../../source/binutils-2.38/configure --target=$TARGET --prefix=$PREFIX --disable-nls --disable-werror
make -j32
sudo make install
cd ..

# 4) Build gcc (step 1):
cd gcc
../../source/gcc-12.1.0/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c,c++ --disable-shared --with-newlib --enable-lto --disable-libstdcxx-pch --disable-nls --disable-werror
make -j32 all-gcc
sudo make install-gcc
cd ..

# 5) Build newlib:
cd newlib
../../source/newlib-4.1.0/configure --target=$TARGET --prefix=$PREFIX --disable-nls
make -j32
sudo make install
cd ..

# 6) Build gdb:
cd gdb
../../source/gdb-12.1/configure --target=$TARGET --prefix=$PREFIX --disable-nls
make -j32
sudo make install
cd ..

# 7) Build gcc (step 2):
cd gcc
make -j32
sudo make install

Topic: Configuration, by Kjetil @ 15/07-2022, Article Link

Terminal Mode Commodore 64 Emulator Disk Support

I have added support for D64 disk images to tmce64 and increased the version number to "0.3". In order to facilitate this several things needed to be added. The CIA emulation has been expanded to include the data ports, which are used to communicate with the disk drives. But the biggest task was to emulate the Commodore IEC serial bus that the KERNAL expects.

The disk and serial bus emulation is by no means complete, and is limited to be able to get a file listing (LOAD"$",8) and loading individual files. Fast loaders will not work and attempting to do anything fancy will probably freeze the emulator.

Stack trace support has also been added to the built-in debugger. There is even support for symbol names, but this is currently just a hardcoded list of certain serial bus functions. Bank switching for the VIC-II chip is also handled in case any programs changes the graphics memory areas.

These changes makes it possible to run the 8-Bit Guy's Attack of the PETSCII Robots in the emulator. Since conversion is done from PETSCII, the reality is closer to "ASCII Robots" though. Since sprites are not supported, use the "C64PETSCII" version of the game.

Some more screenshots:

Attack of the PETSCII Robots Menu

Attack of the PETSCII Robots In-Game

Version 0.3 can be downloaded here but the GitHub repository has also been updated.

Topic: Open Source, by Kjetil @ 02/07-2022, Article Link

VT100 Terminal Emulator on Raspberry Pi Pico

Here is another Raspberry Pi Pico project, this time a DEC VT100 Terminal emulator. Host communication goes through the "standard" UART, composite video is used for the output and a PS/2 keyboard is used for the input. I have named this program "Terminominal".

Since I'm Norwegian I have made some design choices that reflect this. The first is that the composite video uses the PAL standard at 50 Hz. The keyboard scancode handling expects the Norwegian layout, but this can be changed to US layout with a compile time define. Finally the built-in font/character set is ISO-8859-1 (latin-1) compatible.

The composite video (CVBS) is generated by one of the Pico's PIO cores running at 40 MHz, which in turn creates time slices of 0.05 microseconds that affects a lot of the architecture in this program. After taking care of overscan, there is 880 dots on 240 scanlines remaining for the "visible" picture. First I tried using a standard CGA font at 8x8 which would give 110 columns by 30 rows, but the picture was almost unreadable. Instead I designed my own 11x10 font which fits perfectly for a 80 column by 24 rows picture and is quite readable on a CRT display.

The first ARM core reads the UART for incoming bytes and processes these to emulate the VT100 behaviour. Escape codes are processed and then a "screen" array is updated which represents all the characters currently on the screen. The second ARM core fetches characters from this "screen" array, if they have changed, and converts these to scanline and dot information using the font data and puts this into a "frame" array. DMA is used by the PIO core to fetch the "frame" array and push this out on the GPIO pins.

A 2-bit DAC for the video is created by using two resistors. Since the GPIO voltage is 3.3V and the composite video input impedance (on a TV set) is 75 ohms, good values are 680 ohms and 220 ohms for these resistors. It is also possible to use 1000 ohms and 330 ohms, which gives a slightly dimmer picture. The 2 bits gives four signal levels, where one is sync and the other three shades of: black, grey and white.

The PS/2 keyboard protocol is handled by the second PIO core which generates an interrupt once the required 11 bit frame has been read. The interrupt handler converts the scancode to the appropriate byte and sends it out on the UART. Note that since the PS/2 protocol uses 5V and the Raspberry Pi Pico GPIO pins uses 3.3V a level shifter is needed in between!

The VT100 emulation has been tested with vttest and the most important features are supported. VT52 and VT102 modes are not really supported. It should work fine against a Linux host at least. The UART runs at 115200 baud, but can be changed through re-compilation to other speeds.

Here is a block diagram which shows the architecture:

Terminominal Diagram

Here is a connection/function table for the GPIO pins:

| Pin No | Pin Name  | Function   | Connected To            |
| 1      | GP0       | UART TX    |                         |
| 2      | GP1       | UART RX    |                         |
| 6      | GP4       | PS/2 Data  | 3.3V<->5V Level Shifter |
| 7      | GP5       | PS/2 Clock | 3.3V<->5V Level Shifter |
| 21     | GP16      | CVBS DAC   | 680 Ohm Resistor        |
| 22     | GP17      | CVBS DAC   | 220 Ohm Resistor        |
| 36     | 3V3 (OUT) | +3.3V      | 3.3V<->5V Level Shifter |
| 40     | VBUS      | +5V        | 3.3V<->5V Level Shifter |

Here is a breadboard layout created with Fritzing:

Terminominal Breadboard

Notice that the GPIO pins for the composite video is on the other end of the Pico. This was needed because it generates a lot of noise, so much in fact that it affects the PS/2 signalling. This would result in lost bits and parity errors.

A snapshot of version 0.1 can be downloaded here, or check the Git repository here. Check the included for build instructions. It is also possible to compile an SDL version which is used for testing directly on Linux.

I appreciate the good instructions from Van Hunter Adams on how to use DMA on the Raspberry Pi Pico and Javier Valcarce on how to generate PAL video signals.

Here is a photo of Terminominal running on one Pico and connected to another Pico running the kaytil CP/M emulator:

Terminominal and Kaytil

Topic: Open Source, by Kjetil @ 03/06-2022, Article Link

Telephone Handset Connector Replacements

I have some old telephone handsets, where at least one of them seems to date back to the 1930's based on some patents ("British Patents 319837.328926.433234") that I found. All of them had strange connectors incompatible with modern equipment:

Old connection on handset #1

Old connection on handset #2

Old connection on handset #3

But since the speaker and microphone technology has remained mostly the same for over a century, I decided to simply replace the connectors with modern mini jack plugs:

Mini jack plug replacements

This makes it possible to connect them easily to a modern PC and even use them for voice chat.

On the first one the original cable disintegrated when I tried to re-use it, so I replaced the entire cable. This one also has a switch that I wired to pin 8 and 7 on a DE9 connector, so that I can use the CTS/RTS trick to read it through a standard PC serial port.

Handset #1 finished

On the second one I was able to re-use the original cable. This one also has a switch, but I did not wire that up to anything.

Handset #2 finished

On the third one I had issues with a broken wire in the original cable, so that had to be replaced as well. Here I ended up simply re-using the entire cable with connectors from a broken PC headset.

Handset #3 finished

Topic: Repair, by Kjetil @ 13/05-2022, Article Link

CP/M on the Raspberry Pi Pico

A new port is available of my "kaytil" Z80 CP/M 2.2 emulator, this time targeting the new Raspberry Pi Pico.

A snapshot of the "Version 0.2" source can be downloaded here, or check out the Git repository here. The GR-SAKURA version has now also been incorporated into the same tarball and Git repo, instead of residing on a branch.

In the same fashion as the GR-SAKURA version, the CP/M 2.2 and CBIOS binaries are embedded directly into the final binary. For the Pico version this is taken even a step further since the disk images are ALSO embedded into the final binary! This means the disk images are in fact hard-coded and needs to be provided/updated before building. The disk images provided with the source code are just dummies and should be replaced with something more useful.

I figured that embedding the disk images was the easiest way to get things up and running considering the constraints of the Raspberry Pi Pico platform. This works nicely since the Pico has 2MB of Flash and can easily hold four IBM 3740 floppy disk images, typically 256KB in size each. Embedding the disk images is done using objcopy and forcefully placed in the ".rodata" section which causes them to reside in the Pico Flash instead of the SRAM.

The console is available on the "standard" UART at pins 1 and 2 and running at 115200 baud. Conversion between ADM-3A codes to VT100/ANSI codes are done in the emulator in the same way as the other versions.

Building requires the ARM GCC toolchain, CMake and the Pico SDK; just follow the official guide on how to set this up. In typical CMake fashion, create a build folder and call cmake pointing to the "pico/" subdirectory containing the CMakeLists.txt file:

mkdir build
cd build
PICO_SDK_PATH=/path/to/pico-sdk cmake /path/to/kaytil/pico/

The resulting "kaytil.elf" file can be flashed with SWD, or the "kaytil.uf2" file can be copied through USB in the BOOTSEL mode.

Here is a photo showing it in action, using a Commodre 64 as a terminal:

Kaytil on the Pico with a C64 Terminal

For this to work I used a level shifter between the C64 user port and the Raspberry Pi Pico to convert between +5V and +3.3V. In addition I changed the baudrate to 2400 baud by calling "uart_set_baudrate(uart0, 2400)" in "console_init()".

Topic: Open Source, by Kjetil @ 22/04-2022, Article Link

Terminal Mode Commodore 64 Emulator Update

I have performed a massive overhaul of the proof-of-concept C64 emulator I published about last year. This new version,which I have dubbed "0.2" is much more usable.

A major change in the architecture is that the old version was blocking on input from stdin, which is an interesting concept, but not feasible for more advanced usage. It is now based around curses with non-blocking stdin instead. Moving to curses means there is now a lot better support for graphics, including colors if a 256-color terminal is used. Conversion is done from PETSCII to ASCII and will work best as long as the default character sets are used. There is no sprite emulation.

Pressing Ctrl-C at any time will switch to a (non-curses) debugger. In this mode it is possible to dump memory locations and get a CPU trace. In addition there is support for setting read and write breakpoints on memory addresses which breaks back into this same debugger. In order to properly exit the emulator one must also typically enter the debugger and issue a 'q' from there to quit.

The emulator can be run at close to C64 speed (for games) or in "warp mode" where 100% CPU is used (for raw BASIC programs). I also needed to add support for the timers in the CIA since some games rely on these for random number generation. One unique feature is that getting the TOD (Time of Day) registers from the CIA will return the actual clock from the host system.

As before the emulator needs the ROMs from VICE to run, but the location of these can now be specified on the command line in case they are not at the default location.

There is no Datasette (tape) or 1541 (floppy disk) support, but C64 PRG-style programs may be loaded directly from the command line (or debugger) instead. These are injected directly into memory where they are supposed to be for the BASIC "RUN" command to work. Most BASIC programs should probably work, but machine code programs are hit-and-miss.

The new version can be downloaded here and the GitHub repository has also been updated.

Finally, some color screenshots:

BASIC Prompt

Rolling Demo #1

Rolling Demo #2

Lord of the Balrogs

Oslo B0rs


Stock Market

Topic: Open Source, by Kjetil @ 08/04-2022, Article Link

lazyboNES Emulator

Here is a special NES emulator made for the specific purpose of playing Super Mario Bros with text-based graphics, that is, using curses.

The NES graphics is based around a background of 32 by 30 tiles, each 8x8 pixels. This emulator maps each tile to a character in the terminal and you need to resize it to at least 32x30 for everything to fit. In addition to the text based interface, an SDL2 based graphical output can also be run in parallel. Sound and joystick input will always be provided by SDL2, even when running only in text mode.

Although it is technically possible to play with the keyboard directly into the terminal, it is highly recommended to play with a joystick/gamepad instead. Using the keyboard into the terminal means that all input is fed into a non-blocking "standard in" stream, which makes key combinations impossible. E.g. when walking and then jumping, the walk key will get "unpressed" causing Mario to stop.

The emulator is very specific to Super Mario Bros since the characters are directly mapped to its pattern tables. Other games, even if they start, will probably look really bad. Internally NTSC timings are used, so maybe only the USA version will work.

Several shortcuts have been made with regards to the emulation. The PPU (graphics) emulation only supports horizontal scrolling and no vertical scrolling. PPU background/sprite priority is also not implemented, so sprites are always drawn on top of the background. Rendering on the edges is also not hidden away. APU (sound) emulation supports pulse/triangle/noise channels but not the DMC channel, and due to lack of filters and such the sound quality is far from perfect.

The joystick/gamepad is detected on startup if connected, but the button mapping is hardcoded, so edit the source and re-build to change it. Save and load of the state is supported but only in one slot and only in memory, so it's not saved when quitting the emulator.

6502 CPU emulation is a modified version from my Commodore 64 emulator so it contains BCD mode which is not actually present on the Ricoh 2A03 used in the NES. Ctrl+C in the terminal will break into a debugger where various data can be dumped, including a CPU trace if compiled.

Here is picture of both the curses and SDL2 graphic outputs running in parallel:

lazyboNES screenshot

The first version of the source code is available here, but it has also been uploaded to GitHub for possible future developments.

Topic: Open Source, by Kjetil @ 25/03-2022, Article Link

DTMF Sound Generator

This is a simple program to generate DTMF sounds using SDL as used by telephones. Simply pass the "phone number" as the command line argument.

The code:

#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_audio.h>
#include <math.h> /* sin() */

#define AUDIO_SAMPLE_RATE 44100

typedef struct audio_data_s {
  uint32_t sample_no;
  double freq_1;
  double freq_2;
  bool stop;
  bool stopped;
} audio_data_t;

static void dtmf(char c, double *freq_h, double *freq_v)
  switch (c) {
  case '1':
  case '4':
  case '7':
  case '*':
    *freq_h = 1209;
  case '2':
  case '5':
  case '8':
  case '0':
    *freq_h = 1336;
  case '3':
  case '6':
  case '9':
  case '#':
    *freq_h = 1477;
  case 'A':
  case 'B':
  case 'C':
  case 'D':
    *freq_h = 1633;

  switch (c) {
  case '1':
  case '2':
  case '3':
  case 'A':
    *freq_v = 697;
  case '4':
  case '5':
  case '6':
  case 'B':
    *freq_v = 770;
  case '7':
  case '8':
  case '9':
  case 'C':
    *freq_v = 852;
  case '*':
  case '0':
  case '#':
  case 'D':
    *freq_v = 941;

static void audio_callback(void *userdata, Uint8 *stream, int len)
  int i;
  audio_data_t *audio_data;
  double sample;
  double time;
  audio_data = (audio_data_t *)userdata;

  if (audio_data->stop == false) {
    audio_data->stopped = false;

  for (i = 0; i < len; i++) {
    time = audio_data->sample_no / (double)AUDIO_SAMPLE_RATE;
    sample = sin(2.0 * M_PI * audio_data->freq_1 * time);
    sample += sin(2.0 * M_PI * audio_data->freq_2 * time);
    sample /= 2;
    if (audio_data->stopped) {
      stream[i] = 128;
    } else {
      stream[i] = (Uint8)(127 + (sample * 127));
      if (audio_data->stop && stream[i] >= 126 && stream[i] <= 130) {
        audio_data->stopped = true;

int main(int argc, char *argv[])
  SDL_AudioSpec desired, obtained;
  audio_data_t audio_data;
  char *number;

  if (argc != 2) {
    fprintf(stderr, "Usage: %s <number>\n", argv[0]);
    return 0;

  if (SDL_Init(SDL_INIT_AUDIO) != 0) {
    fprintf(stderr, "SDL_Init() failed: %s\n", SDL_GetError());
    return 1;

  desired.freq     = AUDIO_SAMPLE_RATE;
  desired.format   = AUDIO_U8;
  desired.channels = 1;
  desired.samples  = 1024;
  desired.userdata = &audio_data;
  desired.callback = audio_callback;

  if (SDL_OpenAudio(&desired, &obtained) != 0) {
    fprintf(stderr, "SDL_OpenAudio() failed: %s\n", SDL_GetError());
    return 1;

  if (obtained.format != AUDIO_U8) {
    fprintf(stderr, "Did not get unsigned 8-bit audio format!\n");
    return 1;

  for (number = &argv[1][0]; *number != '\0'; number++) {
    audio_data.sample_no = 0;
    audio_data.stop = false;
    dtmf(*number, &audio_data.freq_1, &audio_data.freq_2);
    audio_data.stop = true;


  return 0;


Topic: Scripts and Code, by Kjetil @ 11/03-2022, Article Link

DOS Keyboard Fix TSR

I have an old AST Premium Exec 386SX/20 laptop running DOS. After the mechanical harddisk failed I replaced it with a flashdisk, but after re-assembly some of the keys on the keyboard would no longer work. I traced this to the '.', '', '', '+' and '\' keys, all of which happens to be on one row/column on the keyboard matrix. After further troubleshooting I could find no fault with the keyboard or associated cables, so unfortunately the problem seems to be within the keyboard controller which is embedded into a custom chipset.

Custom AST Actel Chipset

The lack of '.' and '\' makes it hard to navigate around in DOS, so I started looking into a solution. Since it is nearly impossible to find spare parts like that custom chipset I ended up with a software solution, specifically in the form of a TSR.

This TSR hooks into and intercepts the int 16h calls that are used for keyboard services. By pressing Alt+F1 a scancode representing '.' is returned instead. Also Alt+F2 returns '\' and Alt+F3 returns ':'. This will only work for DOS programs like COMMAND.COM or EDIT that actually use the BIOS services. For most games it probably won't work, but luckily the affected keys are seldom used in games.

The code:

org 0x100
bits 16
cpu 8086

section .text
  jmp main

  sti ; Allow other interrupts!
  mov word [int16_incoming_ax], ax ; Store incoming parameter for later use.

  ; Call original interrupt handler:
  call original_int16:original_int16 ; Will be overwritten runtime!

  ; Check if result should be intercepted:
  push bx
  push ax
  mov word bx, [int16_incoming_ax]
  cmp bh, 0x00 ; Check if AH was "Wait for Keypress".
  je int16_check_f1
  cmp bh, 0x10 ; Check if AH was "Extended Wait for Keypress".
  je int16_check_f1
  jmp int16_end_pop_ax

  cmp ax, 0x6800 ; Alt + F1
  jne int16_check_f2
  pop ax
  mov ax, 0x342E ; '.'
  jmp int16_end

  cmp ax, 0x6900 ; Alt + F2
  jne int16_check_f3
  pop ax
  mov ax, 0x2B5C ; '\'
  jmp int16_end

  cmp ax, 0x6A00 ; Alt + F3
  jne int16_end_pop_ax
  pop ax
  mov ax, 0x273A ; ':'
  jmp int16_end

  pop ax
  pop bx
  retf 2

  dw 0

tsr_end: ; TSR end marker.

  ; NOTE: No protection to prevent TSR from being loaded twice or more!

  ; Call DOS to get original interrupt handler:
  mov al, 0x16
  mov ah, 0x35
  int 0x21
  mov word [original_int16 + 3], es
  mov word [original_int16 + 1], bx

  ; Call DOS to set new interrupt handler:
  mov al, 0x16
  mov ah, 0x25
  ; DS is already same as CS, no need to change.
  mov dx, int16_interrupt
  int 0x21

  ; Terminate and Stay Resident:
  mov dx, tsr_end
  shr dx, 1
  shr dx, 1
  shr dx, 1
  shr dx, 1
  add dx, 0x11 ; Add 0x1 for remainder and 0x10 for PSP.
  mov ax, 0x3100
  int 0x21

Assemble it with NASM: nasm fixkeys.asm -fbin -o

Topic: Scripts and Code, by Kjetil @ 25/02-2022, Article Link

Older articles