Robert Price -

RC2026 – Part 4 – Reading the temperature from a BME280 on an RC2014

In my previous posts, I’ve shown how to read the ID value from a BME280 sensor using an RC2014 computer. That’s not very useful in itself, but it is a good building block for getting practical information from the sensor. In this post, I’m going to read the current temperature.

The temperature isn’t returned as a sensible, human-understandable value directly from the sensor. It needs to be calculated using calibration data that the BME280 also supplies. The BME280 datasheet gives us an algorithm to do this.

I also need to tell the BME280 to continually sense; otherwise, it is in sleep mode.

The BME280 is a very well-known sensor, and there are some libraries written for other systems that I can use to verify my work. Adafruit has a BME280 library for the Arduino that is written in C++. I am going to use some of the code from the Adafruit library where possible.

Writing and reading data

My previous post had a transfer routine to handle the bit-banging of SPI data, so I am going to build upon this.

The first routine we need is one to send and receive data of different lengths. I pass in address locations and lengths. The routine will then bit-bang that amount of data.

void write_then_read(const uint8_t *write_data, uint8_t write_length, uint8_t *read_data, uint8_t read_length) {
    // Deselect the BME280 to ensure it's not selected before starting communication.
    io_spi = SELECT | CLK | MOSI;

    // Write data
    for (uint8_t i = 0; i < write_length; i++) {
        transfer(write_data[i]);
    }

    // Read data
    for (uint8_t i = 0; i < read_length; i++) {
        read_data[i] = transfer(0x00); // Send dummy byte to read
    }

    // Deselect the BME280 after communication is done.
    io_spi = SELECT | CLK | MOSI;
}

I need to be able to read in 8 bit, 16 bit, and 24 bit values in little-endian format, both signed and unsigned, as well as to be able to write an 8 bit value. These utility routines can help with that.

void write8(uint8_t reg, uint8_t value) {
    uint8_t write_data[2] = { reg & 0x7F, value }; // Clear MSB
    write_then_read(write_data, 2, NULL, 0);
}   

uint8_t read8(uint8_t reg) {
    uint8_t write_data[1] = { reg };
    uint8_t read_data[1] = { 0 };

    write_then_read(write_data, 1, read_data, 1);
    return read_data[0];
}

uint16_t read16_LE(uint8_t reg) {
    uint8_t write_data[1] = { reg };
    uint8_t read_data[2] = { 0 };

    write_then_read(write_data, 1, read_data, 2);
    return (read_data[1] << 8) | read_data[0];
}

int16_t readS16_LE(uint8_t reg) {
    return (int16_t)read16_LE(reg);
}   

uint32_t read24(uint8_t reg) {
    uint8_t write_data[1] = { reg };
    uint8_t read_data[3] = { 0 };

    write_then_read(write_data, 1, read_data, 3);
    uint32_t value = 0;
    value |= read_data[0];
    value <<= 8;
    value |= read_data[1];
    value <<= 8;
    value |= read_data[2];
    return value;
}

BME280 registers

The BME280 has numerous registers we can read and write to. The ID we retrieve in the previous blog post uses register 0xd0. Adafruit has defined all of these in their library, so I will reuse their code for this.

enum {
  BME280_REGISTER_DIG_T1 = 0x88,
  BME280_REGISTER_DIG_T2 = 0x8A,
  BME280_REGISTER_DIG_T3 = 0x8C,

  BME280_REGISTER_DIG_P1 = 0x8E,
  BME280_REGISTER_DIG_P2 = 0x90,
  BME280_REGISTER_DIG_P3 = 0x92,
  BME280_REGISTER_DIG_P4 = 0x94,
  BME280_REGISTER_DIG_P5 = 0x96,
  BME280_REGISTER_DIG_P6 = 0x98,
  BME280_REGISTER_DIG_P7 = 0x9A,
  BME280_REGISTER_DIG_P8 = 0x9C,
  BME280_REGISTER_DIG_P9 = 0x9E,

  BME280_REGISTER_DIG_H1 = 0xA1,
  BME280_REGISTER_DIG_H2 = 0xE1,
  BME280_REGISTER_DIG_H3 = 0xE3,
  BME280_REGISTER_DIG_H4 = 0xE4,
  BME280_REGISTER_DIG_H5 = 0xE5,
  BME280_REGISTER_DIG_H6 = 0xE7,

  BME280_REGISTER_CHIPID = 0xD0,
  BME280_REGISTER_VERSION = 0xD1,
  BME280_REGISTER_SOFTRESET = 0xE0,

  BME280_REGISTER_CAL26 = 0xE1, // R calibration stored in 0xE1-0xF0

  BME280_REGISTER_CONTROLHUMID = 0xF2,
  BME280_REGISTER_STATUS = 0XF3,
  BME280_REGISTER_CONTROL = 0xF4,
  BME280_REGISTER_CONFIG = 0xF5,
  BME280_REGISTER_PRESSUREDATA = 0xF7,
  BME280_REGISTER_TEMPDATA = 0xFA,
  BME280_REGISTER_HUMIDDATA = 0xFD
};

Setting the sampling rate

The BME280 doesn’t do much unless it’s told to. So we need a routine to turn it on and get it sampling data. There are various configurations defined in the BME280 documentation, but I’m going to lift these values from the Adafruit library, as they have done the hard work of turning them into enum values already.

enum sensor_mode {
    MODE_SLEEP = 0b00,
    MODE_FORCED = 0b01,
    MODE_NORMAL = 0b11
};

enum sensor_filter {
    FILTER_OFF = 0b000,
    FILTER_X2 = 0b001,
    FILTER_X4 = 0b010,
    FILTER_X8 = 0b011,
    FILTER_X16 = 0b100
};

enum sensor_sampling {
    SAMPLING_NONE = 0b000,
    SAMPLING_X1 = 0b001,
    SAMPLING_X2 = 0b010,
    SAMPLING_X4 = 0b011,
    SAMPLING_X8 = 0b100,
    SAMPLING_X16 = 0b101
};

To set the sampling rate, I need to perform several operations. I first put the BME280 to sleep. This allows me to safely update the configuration and control registers.

void setSampling(enum sensor_mode mode, enum sensor_filter filter, enum standby_duration duration) {
    // Set the sensor to sleep mode before changing settings
    write8(BME280_REGISTER_CONTROL, MODE_SLEEP); 

    // Set the humidity oversampling to x1 (0b001)
    write8(BME280_REGISTER_CONTROLHUMID, 0b001);

    // Set the filter and standby duration in the config register
    uint8_t config = (duration << 5) | (filter << 2);
    write8(BME280_REGISTER_CONFIG, config);

    // Set the temperature and pressure oversampling to x1 (0b001)
    // and the mode
    uint8_t control = (0b001 << 5) | (0b001 << 2) | mode;
    write8(BME280_REGISTER_CONTROL, control);
}

Reading the calibration coefficients

I mentioned earlier the need to use calibration data to calculate the temperature. We need to get these values and store them.

typedef struct {
  uint16_t dig_T1; ///< temperature compensation value
  int16_t dig_T2;  ///< temperature compensation value
  int16_t dig_T3;  ///< temperature compensation value

  uint16_t dig_P1; ///< pressure compensation value
  int16_t dig_P2;  ///< pressure compensation value
  int16_t dig_P3;  ///< pressure compensation value
  int16_t dig_P4;  ///< pressure compensation value
  int16_t dig_P5;  ///< pressure compensation value
  int16_t dig_P6;  ///< pressure compensation value
  int16_t dig_P7;  ///< pressure compensation value
  int16_t dig_P8;  ///< pressure compensation value
  int16_t dig_P9;  ///< pressure compensation value

  uint8_t dig_H1; ///< humidity compensation value
  int16_t dig_H2; ///< humidity compensation value
  uint8_t dig_H3; ///< humidity compensation value
  int16_t dig_H4; ///< humidity compensation value
  int16_t dig_H5; ///< humidity compensation value
  int8_t dig_H6;  ///< humidity compensation value
} bme280_calib_data;

bme280_calib_data _bme280_calib;

The calibration data is a mix of signed and unsigned integers of various lengths. I can use the various read functions I defined earlier to read and save these.

void readCoefficients(void) {
  _bme280_calib.dig_T1 = read16_LE(BME280_REGISTER_DIG_T1);
  _bme280_calib.dig_T2 = readS16_LE(BME280_REGISTER_DIG_T2);
  _bme280_calib.dig_T3 = readS16_LE(BME280_REGISTER_DIG_T3);

  _bme280_calib.dig_P1 = read16_LE(BME280_REGISTER_DIG_P1);
  _bme280_calib.dig_P2 = readS16_LE(BME280_REGISTER_DIG_P2);
  _bme280_calib.dig_P3 = readS16_LE(BME280_REGISTER_DIG_P3);
  _bme280_calib.dig_P4 = readS16_LE(BME280_REGISTER_DIG_P4);
  _bme280_calib.dig_P5 = readS16_LE(BME280_REGISTER_DIG_P5);
  _bme280_calib.dig_P6 = readS16_LE(BME280_REGISTER_DIG_P6);
  _bme280_calib.dig_P7 = readS16_LE(BME280_REGISTER_DIG_P7);
  _bme280_calib.dig_P8 = readS16_LE(BME280_REGISTER_DIG_P8);
  _bme280_calib.dig_P9 = readS16_LE(BME280_REGISTER_DIG_P9);

  _bme280_calib.dig_H1 = read8(BME280_REGISTER_DIG_H1);
  _bme280_calib.dig_H2 = readS16_LE(BME280_REGISTER_DIG_H2);
  _bme280_calib.dig_H3 = read8(BME280_REGISTER_DIG_H3);
  _bme280_calib.dig_H4 = ((int8_t)read8(BME280_REGISTER_DIG_H4) << 4) |
                         (read8(BME280_REGISTER_DIG_H4 + 1) & 0xF);
  _bme280_calib.dig_H5 = ((int8_t)read8(BME280_REGISTER_DIG_H5 + 1) << 4) |
                         (read8(BME280_REGISTER_DIG_H5) >> 4);
  _bme280_calib.dig_H6 = (int8_t)read8(BME280_REGISTER_DIG_H6);    
}

Reading the temperature

The example code given in the BME280 datasheet returned the temperature as an integer, but for ease of use, I will want to use a floating-point value. This is simply the value from the datasheet divided by 100 to give us a value in Celsius. This routine makes extensive use of the calibration data from the BME280.

int32_t t_fine;
int32_t t_fine_adjust = 0;

float readTemperature(void) {
    int32_t var1, var2;
    int32_t adc_T = read24(BME280_REGISTER_TEMPDATA);
    adc_T >>= 4;

    var1 = (int32_t)((adc_T / 8) - ((int32_t)_bme280_calib.dig_T1 * 2));
    var1 = (var1 * ((int32_t)_bme280_calib.dig_T2)) / 2048;
    var2 = (int32_t)((adc_T / 16) - ((int32_t)_bme280_calib.dig_T1));
    var2 = (((var2 * var2) / 4096) * ((int32_t)_bme280_calib.dig_T3)) / 16384;

    t_fine = var1 + var2 + t_fine_adjust;

    int32_t T = (t_fine * 5 + 128) / 256;

    return (float)T / 100;
}

Putting it all together

I have enough code to be able to read the temperature from the BME280, so it’s time to put it all together.

The first thing I need to do is reset the BME280. I can do this by writing to the soft reset register. Secondly, I turn on the BME280 and get it sampling. Next, I read the calibration data. Finally, in a loop, I can continually read the temperature and display it to my serial terminal.

int main(void) {
    write8(BME280_REGISTER_SOFTRESET, 0xB6);

    setSampling(MODE_NORMAL, FILTER_OFF, SAMPLING_X16);

    readCoefficients();

    while(1) {
      float temperature = readTemperature();
      printf("Temperature: %.2f°C\n", temperature);
    }
}

Compiling the code

Because I am using floating-point numbers, I need to include the maths library when compiling. I do this using the -lm flag.

The printf command doesn’t handle floating-point numbers by default, so I also need to enable this. This is done using a C pragma.

#pragma printf %f

When I compile the application using z88dk zcc, my command line looks like this.

zcc +rc2014 -subtype=basic -clib=sdcc_iy -lm -v -m -SO3 --max-allocs-per-node200000 bme280.c -o bme280 -create-app

Running the code

It was very satisfying to see real temperatures on screen when I ran the code. The thermostat in my room was set to 18C, so this seems to be working really well.

Temperature readings of 18.39C being shown in a terminal window.

RC2026 – Part 3 – Using a BME280 environmental sensor on an RC2014 with C

In my previous post, I showed how to read the ID register on the BME280 by bit-banging the SPI protocol using Z80 assembly language. I want to be able to read the temperature using the BME280, but this requires the use of floating-point maths to convert the values returned from the device to a value in degrees Celsius. I think this would be a bit too complex to do using Z80 assembly language, so I plan to switch to using C instead.

I have previously written about using the z88dk C compiler with an RC2014, so I won’t fully go over this again. I will rewrite the previous assembly language code to get the ID of the BME280 device and display it on the LEDs.

Pragmas

I need to set a couple of pragma’s in the C code to tell the compiler where to assemble the code and where to set the stack pointer. The assembly language program ran from address 0x9000, so I will do the same here. I will also set the stack pointer to 0xFC00.

#pragma output CRT_ORG_CODE = 0x9000
#pragma output REGISTER_SP = 0xFC00

Z80 IO Ports

To use the Z80’s IO ports from C, I need to use a special function register. The C compiler z88dk uses has a special instruction called __sfr __at that declares a variable at a specific IO port. This variable can then be read from or assigned, and this maps to Z80 in and out instructions. I’m going to be using IO port 0x01 again.

#define __IO_SPI_PORT 0x01
__sfr __at __IO_SPI_PORT io_spi;

Sending and receiving a byte of data using SPI

Sending and receiving a byte of data takes place in parallel, so I’m going to create a C function that takes a byte as a parameter and also returns a byte.

First, I need to include stdint.h to get the required data type of uint8_t. I also need to define the bit masks for MOSI, MISO, CLK, and SELECT.

#include <stdint.h>

#define MOSI 0b00000001
#define MISO 0b00000001
#define CLK  0b00000010
#define SELECT 0b00001000

Now for the actual transfer function.

// Send a byte and receive a byte from the BME280 over SPI. 
uint8_t transfer(uint8_t value) {
    uint8_t received_value = 0;
    for (int i = 0; i < 8; i++) {
        // Set the MOSI line based on the current bit of the value to send,
        // then det the CLK line low.
        if (value & 0x80) {
            io_spi = 0 &~SELECT &~CLK | MOSI; // Set MOSI high and CLK low.
        } else {
            io_spi = 0 &~SELECT &~CLK; // Set MOSI low and CLK low.
        }
        
        // Read the MISO line to get the received bit.
        uint8_t miso = io_spi & MISO; // Read MISO

        // Shift the received value left and add the new bit.
        received_value = (received_value << 1) | (miso ? 1 : 0);
        
        // Pulse the clock line high.
        if (value & 0x80) {
            io_spi = 0 &~SELECT | CLK | MOSI; // Set MOSI high and CLK high.
        } else {
            io_spi = 0 &~SELECT | CLK; // Set MOSI low and CLK high.
        }
        
        // Prepare for the next bit by shifting the value to send left
        value <<= 1;
    }
    return received_value;
}

Reading the ID byte and displaying the result

Now I have a function that can send and receive a byte; I can request the ID byte.

Firstly, I need to make sure the device isn’t selected. Next, I need to request the ID by sending the command 0xD0, then read the returned byte. I need to send a dummy value when reading the returned byte, so I will use 0x00 in this case. Finally, I deselect the BME280 and show the values on the LEDs, as with the assembly language version.

int main(void) {
    io_spi = SELECT | CLK | MOSI; // Deselect the BME280
    transfer(0xD0);               // send the address for the ID register.
    uint8_t id = transfer(0x00);  // Read the ID register.
    io_spi = SELECT | CLK | MOSI; // Deselect the BME280.

    io_spi = id;                  // display the ID value on the output port
    return 0;
}

RC2026 – Part 2 – Using a BME280 environmental sensor on a RC2014

I previously controlled a MAX7219 LED matrix over SPI from my RC2014 computer. Now I want to try another SPI device, the BM280 environmental sensor from Bosch. The code in this article builds on the previous work, so take a moment to read it if you haven’t already.

The BME280 can read temperature, pressure, and humidity. It is a 3.3V device, so I will need a voltage level converter to use it with a 5V RC2014.

The SPI communication will also need to be two-way, as I will need to tell the sensor what values to send me.

I used the following parts (note: Amazon affiliate links)

The regulator allowed me to generate a 3.3v power supply from the RC2014’s 5v supply. I was then able to use this on the low-voltage side of the level shifter to allow the signals to convert between 5v and 3.3v.

As before, I am using the SC129 Digital IO module on my RC2014 to bit-bang the SPI protocol. This is wired up via the level shifters and 3.3V regulator as follows…

SC129	BME280
GND	GND
5V	3.3V (via 3.3 regulator)
OUT D0	SDA / SDI (via level shifter)
OUT D1	SCL / SCK (via level shifter)
OUT D3	CSB (via level shifter)
IN D0	SDO (via level shifter)

The BME280 gives us the following timing diagram for SPI communication.

Looking at the timing diagram, we can see that before we start any communication, the SCL / SCK and CSB lines both need to be high. We can use a subroutine to do this.

deselect_bme280:
    ld a, 0 | SELECT | CLK | MOSI
    out (OUTPUT_PORT),a
    ret

Sending and receiving take place on the transition of the SCK line from high to low.

This code is similar to the code for the LED matrix in my earlier post. I have added some additional code to handle the input. This reads the bit, rotates it right into the carry flag, then rotates that value into the E register. By the end of the routine, the byte in register D will have been sent, and the byte returned will be in register E.

send_receive_byte:
    push bc
    ld b, 8
    ld a, 0 &~SELECT &~CLK | MOSI
    rra
    ld c, a
.transmit_bme280_bit:
    ld a, c
    rl d
    rla 
    out (OUTPUT_PORT), a.  ; CLK low
    in a, (INPUT_PORT)
    rra
    rl e
    ld a, c
    or a, CLK
    out (OUTPUT_PORT), a   ; CLK high
    djnz .transmit_bme280_bit
    pop bc
    ret

To test that this is working, we can send the value 0xD0 to the BME280. It should send back the value 0x60. To read the returned byte, we send 0x00. While this is being sent, the result byte will be returned simultaneously. We will then output this byte to the SC129 so the display LEDs will show the returned value in binary.

bme280_getId:
    call deselect_bme280
    ld d, 0xD0
    call send_receive_byte
    ld d, 0x00
    call send_receive_byte 
    call deselect_bme280

    ld a, e
    out (OUTPUT_PORT), a
    ret

After running, the LEDs correctly show 01100000 – 0x60.

The next step will be to get actual temperature readings. That will be the subject of the next post.

RC2026 – Part 1 – Using a SPI LED Matrix from a RC2014

In this post I show how to use the SPI protocol from Z80 assembly language so an RC2014 computer can control a MAX7219 LED matrix.

For the 2026 RetroChallenge I am exploring using SPI devices from a Z80-based RC2014 computer.

The first device I want to use is an 8×8 LED matrix (Amazon affiliate link). Shelia Dixon has previously developed an 8×8 LED matrix display module for the RC2014; however, this is directly interfaced to the RC2014 using two IO ports. I will be using a single port and communicating with it by bit-banging the SPI protocol.

MAX7219 LED Matrix

The 8×8 LED matrix I’m using is a MAX7219 to handle the SPI communication and control the LEDs. It uses 5 wires from the RC2014

VCC – +5V
GND
CS – Chip Select – This is active low
CLK – Clock – Data is loaded when the clock goes from low to high
DIN – Data In – 1 bit of data

I’m using the SC129 Digital IO module from Small Computing Central on the RC2014 for the digital output. This provides pins suitable for DuPont connectors. You could use the official RC2014 Digital IO module, but you would have to modify it to add connections. In this case, it’s simpler to use the SC129 module. The SC129 is connected to the LED matrix module as follows…

SC129	MAX7219 LED Matrix module
+5V	VCC
GND	GND
OUT D0	DIN
OUT D1	CLK
OUT D2	CS

The MAX7219 gives us this timing diagram to follow when we want to send it data.

So to send data, we need to first take the CS line low. This activates the MAX7219, and it knows to listen for incoming data. Next, we set DIN and take CLK high. This will load the single bit of data on DIN into the MAX7219. Now we take CLK low in preparation for the next bit to be sent. We repeat this 8 times in total to send a byte of data.

The MAX7219 expects two bytes of data to be sent each message. The first byte is an address, the second byte is the data value.

Sending SPI data using the Z80

So how do we do this on the Z80? Well, first we’re going to define some constants to help.

The SC129 is using IO Port 1.

OUTPUT_PORT     EQU $01

As we said earlier, the Data bit is D0, the Clock is D1, and the Select line is D2. We call the Data bit MOSI, which stands for Master Out Slave In.

MOSI            EQU %00000001
CLK             EQU %00000010
SELECT          EQU %00000100

As you can see, we’re using binary to define the location. When we want to set the bit in one of these positions, we can use an OR statement, and when we want to clear the bit, we can AND the Compliment (the inverse).

So to enable the MAX7219 we want the SELECT line to be low, the CLK line to be low, and we will take MOSI high. We can use the following Z80 subroutine to do this.

select_max7219:
    ld a, 0 & ~SELECT & ~CLK | MOSI
    out (OUTPUT_PORT),a
    ret

To disable the MAX7219, we want the SELECT line to be high, the CLK line to be low, and we will take MOSI high.

deselect_max7219:
    ld a, 0 | SELECT & ~CLK | MOSI
    out (OUTPUT_PORT),a
    ret

To send a byte, need to send 8 bits of data. We pass the byte we want to send in the D register. To send a bit of data, we know we need to take SELECT and CLK low. We can prepare this and save it to the E register to reuse each bit. We are going to be shifting data into the MOSI bit, so before we save it to e, we shift it to the right. Now, for each bit we want to send, first load the A register with the value of the cached E register. We then pick up the next bit from the d register by shifting d to the left. This pushes the bit we want to send into the carry flag. We retrieve it by shifting the A register to the left so it sets the value of the carry flag into the MOSI bit. We send this, before ORing the CLK bit to take it high, and sending that.

That was quite a wordy explanation, but here’s the code so hopefully it makes more sense.

transmit_max7219_byte:
    push bc
    ld b, 8
    ld a, 0 &~SELECT &~CLK | MOSI
    rra
    ld e, a
.transmit_max7219_bit:
    ld a, e
    rl d
    rla  
    out (OUTPUT_PORT), a
    or a, CLK
    out (OUTPUT_PORT), a
    djnz .transmit_max7219_bit
    pop bc
    ret

To send a two-byte instruction to the MAX7219, we need to combine the subroutines we’ve built. We need to select the MAX7219, send two bytes, then deselect it. We’ll pass the two bytes in registers b and c.

max7219_write:
    call select_max7219
    call transmit_max7219
    call deselect_max7219
    ret

transmit_max7219:
    ld d, b
    call transmit_max7219_byte
    ld d, c
    call transmit_max7219_byte
    ret

Controlling the MAX7219 using SPI

To tell the MAX7219 to turn on or off a LED, we send a column address in one byte, and the column data in the next. So, 8 columns of bits. However, we also need to send some additional command codes so the MAX7219 knows how to behave.

A full list of commands can be found in the MAX7219 datasheet.

The MAX7219 can interface with 7-segment displays, but we don’t want any of this functionality, so we need to tell it not to decode any incoming display commands. We also want to make sure it is running on a low duty cycle to reduce power usage.

These are the commands I use to initialise the display.

    ld bc, 0x0C00       ; shutdown mode, this ensures the LEDs are off.      
    call max7219_write
    ld bc, 0x0900       ; no decoding
    call max7219_write
    ld bc, 0x0A01       ; 3/32 intensity
    call max7219_write
    ld bc, 0x0B07       ; scan all 7 columns
    call max7219_write
    ld bc, 0x0F00       ; No display test
    call max7219_write

Once setup we can send the image. We send the column number in register b, and the column data in register c. So to send a cross I can use the following.

    ld hl, cross
    ld b, 8
.send_image:
    ld c, (hl)
    inc hl
    call max7219_write
    djnz .send_image

cross:
    dc %00000000
    dc %01000010
    dc %00100100
    dc %00011000
    dc %00011000
    dc %00100100
    dc %01000010
    dc %00000000

Finally, I turn the display on.

    ld bc, 0x0C01       ; normal operation - turn on the display         
    call max7219_write

Building, deploying, and running on the RC2014

To assemble the code, I’m using the SjASMPlus Z80 assembler on my MacBook Pro. The RC2014 is running SCM, so to transfer the assembled code, I need to convert it into Intel hex before sending it across. I use z88dk-appmake to do this. Once across, I run the application using the “g” command in SCM.

So, to assemble my matrix.s source code to address $9000 and send it to my RC2014 using the serial device at /dev/tty.usbmodem03591, I would use the following. First, I would make sure I am connected to the RC2014 over serial using the following…

% minicom -c on --device /dev/tty.usbmodem03591

Next, I would open another Terminal shell and run the following…

% sjasmplus matrix.s --raw=matrix.z80 
% z88dk-appmake +hex --org 0x9000 -b matrix.z80
% cat matrix.ihx > /dev/tty.usbmodem03591

Going back to minicom, I execute the code using the following…

g 9000

This will run the transmitted code, and my image will appear on the LED matrix.

Update

It’s been pointed out to me that the newer versions of SjASMPlus support the building of Intel HEX files directly, so we can skip the z88dk-appmake step. To build the hex files in SjASMPlus, we can use the following…

% sjasmplus matrix.s --hex=matrix.ihx

RC2026 – Taking part in Retro Challenge 2026

After taking part in the very enjoyable RetroChallenge in 2024 and 2025, I’ve decided to take part again in 2026.

This year, my plan is to use the SPI prototcol so my RC2014 computer can talk to various other SPI supporting devices.

SPI stands for Serial Peripherial Interface. It uses synchronous serial communication allowing a “master” to talk to “slave”. This gives us two lines MOSI – Master Out Slave In, and MISO – Master In Slave Out. There is a also a Clock line where 1 bit of data is sent and received each pulse of the clock, and a Select line that is used to activate a device. This allows multiple devices to share the same Clock, MOSI, and MISO lines, while using individual Select lines.

The Z80 microprocessor the RC2014 uses does not natively support SPI, so I will need to put together some basic hardware as well as writing software to support it.

Making a Jurl ROM Cartridge for the ZX Spectrum

If you are interested in Retro Computing, then you have probably come across Johnny Blanchard and his quest to port his game Jurl to as many platforms as possible.

One of those platforms is the Sinclair ZX Spectrum. You can name your price to download a copy of Jurl for the ZX Spectrum.

I’ve recently become interested in how ROM cartridges work on the ZX Spectrum. They were initially introduced by Sinclair Research with the release of the ZX Interface 2. This was a joystick interface that supported two Atari style 9 pin joysticks, and included a slot for a ROM cartridge. When a ROM cartridge was inserted and the Spectrum powered up, the internal ROM in the Spectrum would be disabled and replaced with the ROM in the cartridge. This meant games or other code on the cartridge would run instantly without needing to be loaded from cassette. However, it also meant games could not rely on any routines in Spectrum ROM, and must be standalone. The ROM cartridge is 16 kilobytes in size.

Looking at Jurl, the binary is 27,353 bytes in size. This is larger than the 16k size limit of the ROM cartridge. However, we can use compression to squeeze Jurl so it fits into a 16k cartridge. If we use ZX0 compression, we can shrink Jurl down to just 11,598 bytes.

Let’s start to put our ROM code together.

The code on the ROM will always start to execute from address 0. We can’t be sure the contents of the RAM will be blank. We could zero all the contents of the RAM, but it would be quicker to just make sure the BORDER, PAPER, and INK are all set to black so the user doesn’t see anything they shouldn’t.

The border is set using a Z80 out instruction to port 254. The paper and ink can be setting the attribute area of the screen memory to 0. This starts at address $5800 and is 767 bytes long. We can use a Z80 ldir instruction to quickly clear this.

; first, set the border to black
    ld a,0
    out (254),a           ; border black

; now set the background paper and ink to black by filling the attribute
; memory with 0s. 
    ld hl,$5800           ; attribute memory start
    ld de,$5801           
    ld bc,767
    ld (hl),a
    ldir                  ; fill all 768 attributes

Now we have a black screen, we can decompress the game and start it. We set the location of the compressed game in the HL register pair, and the destination address in DE before we call the ZX0 decompression routine. Once the game has decompressed we can just call it. We add a jump back to the call instruction incase the game returns. This ensures the game will just restart.

 ; decompress the game code into memory at gamelocation.
    ld hl,jurldata
    ld de,gamelocation 
    call dzx0_standard

; run the game code.
.game_loop:
    call gamelocation

    jp .game_loop

Remember I said that the Spectrum’s ROM was replaced by the contents of the cartridge? Well, this causes a couple of problems as Jurl is expecting two things to be available in specific locations in the ROM. For the game to work, we will need to fix this.

Firstly, Jurl expects the Z80 to be running in IM1. This is interrupt mode 1 which means the Z80 will be interrupted periodically and will execute code at address $38. This would normally handle things like reading the keyboard, but Jurl doesn’t actually do anything with the data the interrupt is handling. This means we just need to handle the interrupt and return. So at address $38 we add the following.

im1:
    ei     ; re-enable interrupts
    reti   ; return

Secondly, Jurl also expects the ZX Spectrum’s font be available at address $3D00. I used the memory dump option in the Fuse emulator to save the font from the Spectrum’s ROM. I can then just include this binary data into my ROM at the correct address.

Once the source code has been assembled, the ROM cartridge binary can be tested in Fuse using the Media -> Cartridge menu option.

Building a physical ROM cartridge

Now I have a working binary, I can create a physical ROM cartridge to use in my ZX Interface 2.

The ROM cartridge slot exposes address and data lines, as well as MREQ. I have several W27C512 EEPROMs I can use in the cartridge. This is a 64k cartridge but as I only need 16k, I can tie lines A14 and A15 to ground. I can also use a 74HCT32 OR gate to enable the EEPROM when A14, A15, and MREQ are all low.

Now I have a circuit, I can use this to create a PCB. I have used EasyEDA to layout the PCB and also include a graphic of the spaceship from the loading screen.

I sent the PCB design off to be manufactured, and when the boards arrived in the post I soldered one up and tested it out.

The card works well, and I now can play Jurl on my 48k ZX Spectrum instantly.

Acknowledgements

Before sharing this project, I wrote to Johnny to get his approval as the game is under copyright. I am very grateful that he kindly gave permission for me to share this.

RC2025 – Part 9 – Using a SNES controller

The RetroChallenge may have finished, but I have a few more things to add.

Chartreuse on Mastodon pointed out that the SNES controller is quite like the NES controller. Instead of returning a single byte, it returns two bytes. The first byte is the same as the NES controller; the second contains extra buttons.

I wanted to see if my existing work could be easily extended to use a SNES controller, so I bought one on AliExpress. I also bought a SNES extension lead so I could cut it in half and add Dupont sockets to the wires. This means I could wire it directly to the RC2014 module I designed for the NES controller using one of the debug connectors I added to the PCB.

The SNES controller uses a different connector, but the pins work in the same way. This diagram shows the 5 pins we are interested in, and how we need to wire them up to the RC2014 NES controller module.

The SNES cable wired up via dupont connectors to the RC2014

Writing a reusable Z80 routine

As there are two bytes being returned, I can’t just call my get_buttons routine. This will toggle the Latch twice, so I will never get the extra buttons.

Instead, I have to toggle Latch one at the start of the routine, and call a cut down version of the original get_buttons routine that reads the 8 bits twice. The first byte returned will be the original NES buttons. The second byte will be the extra buttons on the SNES controller. Instead of returning a single byte in register a, I will instead use register pair de. Register d will hold the NES button data, and register e will hold the SNES button data.

; SNESController.inc
; Definitions and subroutine to read SNES controller button states
; Robert Price - 1st November 2025


; The Z80 port address to use for the controller interface.
NES_PORT    EQU $01

; The bit masks for the controller interface lines.
CLOCK   EQU $01
LATCH   EQU $02
DATA    EQU $01


; subroutine to read the NES controller button states.
; returns the button states in DE registers.
; register D contains the high byte, and register E the low byte. 
; All other registers are preserved.
; The high byte is like the NES controller, low has the extra SNES buttons.
get_buttons:
        push af           ; save af registers
        push bc           ; save bc registers

; pulse the LATCH line low to high and back to low again.
        xor a               ; set a to 0 
        out (NES_PORT), a
        ld a, LATCH
        out (NES_PORT), a
        xor a               ; set a to 0
        out (NES_PORT), a

        call .get_buttons
        ld d, a             ; store the button states in register d
        call .get_buttons
        ld e, a             ; store the button states in register e

        pop bc              ; restore bc registers
        pop af              ; restore af registers

        ret                 ; return to caller with button states in a


.get_buttons:
; setup the loop counter to read 8 buttons.
        ld b, 8             ; 8 buttons to read. 

; now we rebuild the byte into register c. As we are setting all 8 bits,
; we don't need to worry about clearing c first.
.loop:
; read the controller button states
        in a, (NES_PORT)    ; read the DATA line

; move the DATA bit into register c to rebuild the send byte
        srl a               ; shift right to get the DATA bit into carry
        rr c                ; rotate carry into bit 7 of c

; pulse the CLOCK line to read the next button.
        ld a, CLOCK
        out (NES_PORT), a
        xor a               ; set a to 0
        out (NES_PORT), a

; loop to read all buttons.
        djnz .loop

; return the button states in register a
        ld a, c             ; put the final button states in a 
        ret

Using the new Z80 routine

To test the new routine, I can use LEDs as before. I have two modules that can display an 8-bit value using LEDs. A RC2014 Digital IO module at IO address 0, and a SC134 module at IO address 2. I will display one returned byte on one of the modules, and the second returned byte on the other module. This can be run using SCM as before.

 ; A simple button reading program for the RC2014 Z80 computer running SCM
 ; this version outputs the SNES button states to a LED output
 ; Robert Price - 1st November 2025

        ORG $9000

; the Z80 port address to use for the LED output.
; This expects two Digital IO ports to be connected to the RC2014,
; one at IO address 0 for the high byte, and one at IO address 2 for the low byte.
LED_PORT_H  EQU $00
LED_PORT_L  EQU $02

main:
; get the button states from the SNES controller
        call get_buttons     ; call the get_buttons subroutine
        ld a, d              ; get the high byte button states
        cpl                  ; invert the bits in register a so pressed buttons are 1, and unpressed are 0
        out (LED_PORT_H), a  ; output the button states to the LED port

        ld a, e              ; get the low byte button states
        cpl                  ; invert the bits in register a so pressed buttons are 1, and unpressed are 0
        out (LED_PORT_L), a  ; output the button states to the LED port

        jr main              ; repeat forever

        INCLUDE "SNESController.inc"

        END

RC2025 – Part 8 – Playing Manic Miner with an NES controller

I’ve made good progress with my RetroChallenge to get an NES controller working on my RC2014 computer.

I wanted to be able to play a game with the controller. I had hoped to write my own, but with only a few days left, I didn’t think this was practical. Instead, I wondered about hacking an existing game.

While it’s not an RC2014, the Sinclair ZX Spectrum is also based on the Z80 processor. Colin Piggot makes a ZX Spectrum Bus Interface that allows RC2014 cards to be plugged into a Speccy.

As the RC2014 NES controller module can now be plugged into a Speccy, could I adapt one of my favourite games to work with it? Could Manic Miner be playable with an NES controller?

The first step was to try to disassemble Manic Miner to see how the existing Kempston joystick support worked. I was hoping it would be simple to just wire in NES controller support there.

I made a start on this myself, before thinking that for such an iconic game, someone must have done this before. A quick search revealed an excellent commented disassembly of Manic Miner by Richard Dymond.

Faking a Kempston joystick

The Kempston joystick interface works by using a Z80 in operation on port 31. I would need to fake this by calling a routine to read the NES controller and return data in the Kempston format.

The Kempston joysticker interface returns the following in a single byte.

Bit	Value
0	Right
1	Left
2	Down
3	Up
4	Fire
5	N/A
6	N/A
7	N/A

So, if the Fire button is being pressed, bit 4 will be 1.

I can modify the get_buttons routine I previously wrote to read the NES controller and return the data in this format.

To do this, before the pop bc instruction, I can add the following code.

; build the kempston joystick byte in register a
        xor a               ; clear a
        
.test_fire:
        bit NES_A_BTN, c
        jr nz, .test_up
        set 4, a
.test_up:
        bit NES_UP_BTN, c
        jr nz, .test_down
        set 3, a
.test_down:
        bit NES_DOWN_BTN, c
        jr nz, .test_left
        set 2, a
.test_left:
        bit NES_LEFT_BTN, c
        jr nz, .test_right
        set 1, a
.test_right:
        bit NES_RIGHT_BTN, c
        jr nz, .done
        set 0, a
.done:
        pop bc              ; restore bc registers

Here I am clearing the a register so all bits have a default value of 0. Next, I am testing the bits in the byte I built to store the values from the NES controller. If the bits are set in the NES byte, then I set the relevant bit in the Kempston byte.

Hacking Manic Miner

My original idea was to load Manic Miner into a Spectrum, then use a Multiface to poke my changes into memory. Although this would work, I decided it would take too long and would be harder to save my work.

Instead, I downloaded a clean .tap file of Manic Miner from World of Spectrum and loaded this into the ZEsarUX emulator. ZEsarUX will let me poke my changes into the game and save the results as an SNA file. I can use the SNA file on a DivMMC connected to my Spectrum to load the game. This means I can make sure the game is still working before saving my changes.

I needed to find a place to store my get_buttons routine in Manic Miner. Upon examining the disassembly, remnants of the source code from when Matthew Smith was writing the game are visible at 0x934c. This space is unused in the game, so it’s safe for me to put my code there.

; A simple button reading program for the RC2014 Z80 computer running SCM
; This will pretend to be a Kempston joystick interface, and return bits like that interface.
; Robert Price - 24th October 2025

        ORG $934c

; The Z80 port address to use for the controller interface.
NES_PORT    EQU $01

; The bit masks for the controller interface lines.
CLOCK   EQU $01
LATCH   EQU $02
DATA    EQU $01

NES_A_BTN      EQU $00
NES_UP_BTN     EQU $04
NES_DOWN_BTN   EQU $05
NES_LEFT_BTN   EQU $06
NES_RIGHT_BTN  EQU $07


; subroutine to read the NES controller button states.
; returns the button states in register a.
; all other registers are preserved.
get_buttons:
        push bc           ; save bc registers

; pulse the LATCH line low to high and back to low again.
        xor a               ; set a to 0 
        out (NES_PORT), a
        ld a, LATCH
        out (NES_PORT), a
        xor a               ; set a to 0
        out (NES_PORT), a

; setup the loop counter to read 8 buttons.
        ld b, 8             ; 8 buttons to read. This will be decremented to 0.

; now we rebuild the byte into register c. As we are setting all 8 bits,
; we don't need to worry about clearing c first.
.loop:
; read the controller button states
        in a, (NES_PORT)    ; read the DATA line

; move the DATA bit into register c to rebuild the send byte
        srl a               ; shift right to get the DATA bit into carry
        rr c                ; rotate carry into bit 7 of c

; pulse the CLOCK line to read the next button.
        ld a, CLOCK
        out (NES_PORT), a
        xor a               ; set a to 0
        out (NES_PORT), a

; loop 8 times to read all buttons.
        djnz .loop

; build the kempston joystick byte in register a
        xor a               ; clear a
        
.test_fire:
        bit NES_A_BTN, c
        jr nz, .test_up
        set 4, a
.test_up:
        bit NES_UP_BTN, c
        jr nz, .test_down
        set 3, a
.test_down:
        bit NES_DOWN_BTN, c
        jr nz, .test_left
        set 2, a
.test_left:
        bit NES_LEFT_BTN, c
        jr nz, .test_right
        set 1, a
.test_right:
        bit NES_RIGHT_BTN, c
        jr nz, .done
        set 0, a
.done:
        pop bc              ; restore bc registers

        ret                 ; return to caller with button states in a

I compiled the code using the sjasmplus assembler on my Mac, and this gave me a 61-byte block of assembled code. Running this through hexdump gave me the following hex code to poke into memory.

9c4c  c5 af d3 01 3e 02 d3 01  af d3 01 06 08 db 01 cb
9c5c  3f cb 19 3e 01 d3 01 af  d3 01 10 f1 af cb 41 20
9c6c  02 cb e7 cb 61 20 02 cb  df cb 69 20 02 cb d7 cb
9c7c  71 20 02 cb cf cb 79 20  02 cb c7 c1 c9

I used the Hexadecimal Editor in the Debug Menu of ZEsarUX to input this.

Now I needed to call this when the Kempston joystick was being called from the game.

The first place this is done is at address 0x8878. This code checks if the fire button is being pressed in demo mode.

8878	LD A,($8459)	Pick up the Kempston joystick indicator from 8459
887B	OR A	        Is there a joystick connected?
887C	JR Z,$8884	Jump if not
887E	IN A,($1F)	Collect input from the joystick

In this case, I don’t need to check the joystick indicator, so all 4 instructions can be replaced with the following.

8878    CALL $934C
887B    NOP
887C    NOP
887D    NOP
887E    NOP
887F    NOP

The NOP instructions tell the Z80 to do nothing. I am just using them to fill up the space that the 4 original instructions were using. The assembled code looks like this, and it was loaded using the hexadecimal editor.

8878  cd 4c 93 00 00 00 00 00

The next block of code looks for left or right being pressed at address 0x8C24

8C24	LD A,($8459)	Collect the Kempston joystick indicator from 8459
8C27	OR A	        Is the joystick connected?
8C28	JR Z,$8C34	Jump if not
8C2A	LD BC,$001F	Collect input from the joystick
8C2D	IN A,(C)

I can use the same code as before to drop in there, but I need an extra 3 NOP instructions to fill up the space. The replacement hex code looks like this.

8C24  cd 4c 93 00 00 00 00 00 00 00 00

There is similar code to check the fire button at address 0x8c6c. I can poke in the same hex code there.

8C6C  cd 4c 93 00 00 00 00 00 00 00 00

Finally, there is a routine at 0x9337 that checks if the fire button is being pressed. This is a shorter version like the code at 0x8878, so I can poke in the same code there.

9337  cd 4c 93 00 00 00 00 00

I can now save a snapshot of the game. I do this using the Snapshot option in ZEsarUX and making sure I use a .SNA file extension. I called my file MMNES.SNA. It’s available to download for anyone following along.

Copying this to an SD card and placing it in the DivMMC allowed me to load the modified game on my Spectrum.

A screenshot of Manic Miner's first level - The Central Cavern

Conclusion

While I hadn’t planned to hack a Spectrum game as part of the RetroChallenge this year, it’s turned out to be a great diversion and learning experience. It’s still using the code and hardware developed on the RC2014.

The joypad works well, and although it is using a little more CPU time, it’s not noticeable when playing the game. It doesn’t have the nostalgia value of using the Spectrum’s rubber keys, but it is responsive and comfortable to use.

The NES Controller module connected to a Spectrum with the Quazar bus interface.

RC2025 – Part 7 – Moving a pixel with a NES controller

In previous posts, I’ve covered how to read an NES controller from an RC2014 computer, and also how to use an 8×8 LED matrix. I now want to combine these and use the NES controller to move a pixel on the LED matrix.

The first thing we want to do is to draw a pixel in the top left corner of the LED matrix. To do this, I’ll use register b for the Row data and register c for the Column data. We need to set a single bit in each because we only want a single pixel lit.

        ORG $9000

ROW     EQU 0
COLUMN  EQU 2

setup:
        ld b, 0b00000001  ; Row bit for the pixel
        ld c, 0b10000000  ; Column bit for the pixel

main:

.draw_pixel:
        xor a             ; clear a
        out (COLUMN), a   ; clear the columns
        ld a, b           ; get the current row bit
        out (ROW), a      ; select the row
        ld a, c           ; get the column data for this row
        out (COLUMN), a   ; output the column data

        jr main           ; repeat forever

        END

Now that we have a pixel, we need to read the NES controller and react to movement on the joypad.

We can use Z80 rlc and rrc operations to move the single bit to the left or right in the Row and Column registers. If we reach the end of the byte, the bit will roll over to the other end of the byte.

To test which button is being pressed, we can use a bit operation. If the button isn’t being pressed, we can jump ahead to test the next button.

In our main loop, we can add the following.

UP_BTN   EQU $04
DOWN_BTN EQU $05
LEFT_BTN EQU $06
RIGHT_BTN EQU $07

main:
        call get_buttons   ; Get NES controller button states in A

.test_left:
        bit LEFT_BTN, a
        jr nz, .test_right
        rlc c
.test_right:
        bit RIGHT_BTN, a
        jr nz, .test_up
        rrc c
.test_up:
        bit UP_BTN, a
        jr nz, .test_down
        rrc b
.test_down:
        bit DOWN_BTN, a
        jr nz, .draw_pixel
        rlc b

.draw_pixel:

We also need to include the get_buttons routine we previously wrote. This returns the buttons being pressed on the NES controller in register a.

        INCLUDE "NESController.inc"

        END

At the moment, this is executing far too fast, so we end up with an entire row or column being lit. We need to add a delay. We can write a very simple Z80 routine to just loop X times as a simple delay.

delay:
        ld de, 50000
.delay_loop:
        dec de
        ld a, d
        or e
        jr nz, .delay_loop
        ret

The final working code

Putting this all together, we end up with the following code…


; A simple program to move a pixel on an 8x8 LED matrix
; connected to the RC2014 Z80 computer.
; Robert Price - 19th October 2025

        ORG $9000

ROW     EQU 0
COLUMN  EQU 2

UP_BTN   EQU $04
DOWN_BTN EQU $05
LEFT_BTN EQU $06
RIGHT_BTN EQU $07

setup:
        ld b, 0b00000001  ; Row bit for the pixel
        ld c, 0b10000000  ; Column bit for the pixel

main:
        call get_buttons   ; Get NES controller button states in A

.test_left:
        bit LEFT_BTN, a
        jr nz, .test_right
        rlc c
.test_right:
        bit RIGHT_BTN, a
        jr nz, .test_up
        rrc c
.test_up:
        bit UP_BTN, a
        jr nz, .test_down
        rrc b
.test_down:
        bit DOWN_BTN, a
        jr nz, .draw_pixel
        rlc b

.draw_pixel:
        xor a             ; clear a
        out (COLUMN), a   ; clear the columns
        ld a, b           ; get the current row bit
        out (ROW), a      ; select the row
        ld a, c           ; get the column data for this row
        out (COLUMN), a   ; output the column data

        call delay        ; small delay to make movement visible

        jr main           ; repeat forever

delay:
        ld de, 50000
.delay_loop:
        dec de
        ld a, d
        or e
        jr nz, .delay_loop
        ret

        INCLUDE "NESController.inc"

        END

Here is a video of the code in action.

RC2025 – Part 6 – Using an 8×8 LED matrix from Z80 assembly language

As part of the 2025 RetroChallenge I’ve been developing an NES controller module for the RC2014 computer.

Up until now, I’ve just been outputting to a terminal. However, I’d like to use something a bit more visual on the RC2014. I’ve decided to use Peacock Media’s 8×8 LED matrix module for this.

The module works by outputting an 8-bit value to one IO port for the row and another 8-bit value to another IO port for the column. These describe which LEDs should be enabled. Each bit in the byte refers to either a row or a column.

The default IO port for the row is 0, and the default IO port for the column is 2.

If I want the top left corner to light, I need to set bit 8 of the column and bit 1 of the row.

If you have the SCM (Small Computer Monitor) program running on an RC2014, you can quickly test it out using the following.

o 0 1
o 2 80

This sets the row to hexadecimal 1, which in binary is 00000001, and the column to hexadecimal 80 which in binary is 1000000.

A smiley face in BASIC

In the documentation for the 8×8 module, Shelia Dixon gives us an example BASIC program to draw a smiley face.

This works by rapidly updating the pixels rather than keeping them permanently on. Repeated fast enough, persistence of vision makes the LEDs appear to be on constantly.

10 FOR I=0 TO 7
20 READ R,C
30 OUT 2,0 : OUT 0,R : OUT 2,C
40 NEXT I
50 RESTORE
60 GOTO 10
1000 DATA 1,60, 2,66, 4,169, 8,169
1010 DATA 16,133, 32,185, 64,66, 128,60

A smiley face in Z80 assembly language

I wanted to convert the BASIC program to Z80 assembly language to help me better understand how this works.

I take a similar approach to the BASIC program. I iterate over a loop 8 times to represent the current Row. I keep this counter in register b. In register c, I keep the current bit the row is pointing to. In each iteration, I read a byte of data from memory that represents the Column. The position in memory is pointed to by register pair hl. Once the data has been output, I then shift the value in register c to the right so it points to the next row.

The final code looks like this.


; A simple program to display a smiley face on an 8x8 LED matrix
; connected to the RC2014 Z80 computer.
; Robert Price - 19th October 2025
;
; Based on the original BASIC example by Shiela Dixon
        ORG $9000

ROW     EQU 0
COLUMN  EQU 2

main:
        ld b, 8           ; 8 rows to display
        ld c, 0b10000000  ; start with bit 7 set for row 8
        ld hl, data       ; point to the smiley data
.loop:
        xor a             ; clear a
        out (COLUMN), a   ; clear the columns
        ld a, c           ; get the current row bit
        out (ROW), a      ; select the row
        ld a, (hl)        ; get the column data for this row
        out (COLUMN), a   ; output the column data
        inc hl            ; point to next row data
        srl c             ; shift to next row bit
        djnz .loop        ; loop for all 8 rows        

        jr main           ; repeat forever

data:
        db 0b00111100     ; 60
        db 0b01000010     ; 66
        db 0b10111001     ; 185
        db 0b10000101     ; 133
        db 0b10101001     ; 169
        db 0b10101001     ; 169
        db 0b01000010     ; 66  
        db 0b00111100     ; 60

        END