Retro Computer Build Part 5 – Revised Address Decoder

So, after a couple of weeks since writing the first post about this Micro, I’m rethinking the address decoding and mapping of the same. Currently, address line A15 is being used to select between the lower 32K of memory and the upper 32K of memory. In the lower 32K of memory, I will page 32K block of RAM in and out, as needed. While the upper 32K of memory will be used for ROM and video RAM. I had previously suggested using a 3-8 line decoder to break up the upper 32K of memory into 4K chunks and then join a few of them to give 8K chunks. After a few days of writing the post about address decoding, I realised there were a few options available.

If I use a 2 to 4 line decoder (74HC139), I can use address lines A14 and A13 to break the upper 32K of memory into 4 x 8K blocks (which makes it easier for memory management). The upper 3 x 8K blocks can be used for firmware. I can potentially look at paging out one or two of these 8K blocks.

The lower 8K page can be sub divided into 4 x 2K blocks using another 2 to 4 line decoder (74HC139) on address lines A12 and A11. One of these 2K blocks can be used for basic video memory.  If I add a second or third 2K block this would give 4K or 6K of video memory, which would suffice for a basic 40 column x 25 line or 80 column by 25 line display (with some basic colours and cursor functions).

The lower 2K block can be sub divided into 8 x 256 byte pages for I/O. This is still allot of wasted address space for I/O, so what can be done to be more efficient with the memory usage?

We can use a programmable logic device , a “PLD”, to manage the control logic for the I/O. This way we can re-program the PLD at a future date to incorporate any additional changes to the I/O that we may want.

Using an Atmel ATF22LV10C will give us up to 10 outputs each, which can be individually assigned to one or more addresses. With up to 12 address inputs, the PLD makes it easier to map the control lines required. The unused pins on this device will be brought out to a header in case we need to use these pins at a later date. This is a  simpler solution to the multiple address decoders and additional logic ICs that potentially we were looking at.

When looking at the above revised memory map, we can see the I/O region is spread over 256 bytes of memory.

ATF22LC10C Datasheet

Years ago I used us a Hi-Lo Programmer that connected to my PC via an ISA card. This device was supplied with its own DOS program for taking Boolean logic and producing a map file which could be programmed into a PLD or a GAL. As I can’t use this anymore on modern PCs or a laptop, I need to find a more modern solution.

So I purchased a G540 programmer on eBay for very little money. The G540 was supplied with some adaptors for PLCC devices. A chip extractor was also supplied with this package. This programmer has a USB port, so it can connect to my laptop or desktop PC.

eBay G540 programmer

Atmel has a utility call WinCupl which allows you to write Boolean logic and create a map file which can be programmed into the 22LC10 PLD. I’ve never used this program before, so a little bit of study will be needed.


Binary to 7 Segment Hex Decoder

While working on the Retro Computer Project, I was looking to build a small interface that would let me connect to the address and data bus of the Micro to provide a method to manually program the micro as well as read/write  data into memory.

Back in the last century there was a logic IC that provided this function, but I couldn’t find it anywhere. There were plenty of the BCD to 7 segment decoders, but nothing that would give values above 9 such as A, B, C, D, E & F.

Time for a quick project and to quickly put something together! So I looked at what I had available and had a boot load of PIC 16F628 Micro controllers. So if you can’t find what you are looking for, build it!

As my goal was to get something to put together in a couple of hours that I could use quickly, I was not thinking about how efficent the code would be, so there may be better ways of doing this. Please feel free to take the code and schematic for this Binary to Hex 7 Segment decoder and use it for your own projects. All I ask is that you link or reference back to me and this project.

With this project, the first step was to define my requirements, my outputs and inputs. Obviously I needed to drive a 7 Segment LED display (common cathode). I needed an input to latch data into the decoder and wanted to have a test function as well as a blanking input.

The Hardware

I used the internal oscillator on the PIC as the clock, set to 4MHz. The main loop in the code checked to see if any of the control lines were active. If any of these control lines were active (low) the PIC microcontroller would perform the necessary action. The data for the decoder was latched into the buffer prior to decoding.

Bin2Hex_Schematic (PDF)

Hex27Seg (KiCAD Project)

You can ignore the switches to the left of the PIC in the schematic, as there were just used to simulate the control lines and the data input. The resistors to the right of the PIC were just current limiting resistors for each of the 7 segments in the LED display.

The Code

The code was fairly simple and can be broken down it to a few sections. The first being the port setup code. As the PIC has many multi-function pins, its very important to set these correctly at the start. One mistake that I made was to forget to turn off the analogue comparators on PORT A, ended up wasting an hour looking at this, until the penny dropped.

In the main loop of the program, I started by reading the data on PORT_A and then performed a test to see if any of the control lines had gone active low.

You will notice in the code, that the first test performed is for the Blanking Input – if this was not active then the code would check for the Test Display Input. As this was nested inside the if-else statement for the Blanking Input, the Blanking Input had priority over the Test Display. This was one simple way to implement such logic.

When the control lines were active, I wanted to ignore any update from the Latch line, so a simple flag was used to achieve this.

The code for then managing the  control lines was very simple. It could well have been included in the main. I have found by experience, it is always better to have separate function code block for every action. This makes the main code loop easier to read and when you’re troubleshooting, you’re not finding yourself going back over blocks of code again.

In this screen shot you can see the first few lines of the code for the section that converted the binary data into values for the 7 Segment display. In the first line of code I was performing a logical AND to clear out the upper bits of the data, as these bits were the control lines on PORT_A.

Next I compared the data with values from 0 to F inclusive. Based on the value I switched on the different segments of the LED display. I left the formatting of this in binary as I thought this might make it easier for other to read.

You will notice in the code segment above, there is a line that is commented out. This was my debug function, which was used to flash the LED decimal point x number of times, to indicate the value of the data input. This is a good point to bring up. When building any system large or small, it’s always handy to have some form of debugging build in. Just having a simple LED to flash, can save a engineers time, as there is nothing better than a visual indicator to let the person know that they have reached that point in the code.

The source code for the project which was developed in MPLABX is included below. Please feel free to copy and modify the code as you need for your project. I’m just going to program 6 of these for the Retro Computer Project and build the interface board next.

Project C Source Code (Zipped)

Retro Computer Build Part 4 – Initial Firmware

At this stage we have the main control signals of the Micro setup. The address decoder is also setup and I have some thoughts already on changing this. The first ROM is now connected as is the console port via the MAX222.

Now we need some code to load into the ROM to see if the computer is actually running. For this, we are going to use assembly language, which is the closest we can get to the bare metal of the CPU. We could go down to machine code level programming but this project is meant to be fun not torture!

We can see from the above screen shot that Assembly Language is easier to read than Machine Code. Yes, in the early days of computers, programs were developed in machine code, then assembly, then more higher level languages such as C and C++.

Today there are many different high level programming languages for computers, such as Python, Ruby and C# to name just a few. These high level languages are used to make programming easier and quicker for us humans, but the computer still needs machine code to run. So when a programmer is finished writing their program, they will compile the program  to produce code that will eventually run as machine code. This is a simplified version of what happens on your PC or Mac, but the end result is the same.

So we’re going to program in Assembly and for this  we will need a Cross Assembler. A Cross Assembler is a program that operates on one type of computer and produces code that will run on a different type of computer. I’m going to use the ASxxxx Cross Assembler program by Alan R. Baldwin, which can be found in the links below. This tool supports a wide range of CPU including the Z80 and 6502.

Another program that will be needed is a Text Editor. We can’t use programs such as Word, Pages or other modern word processor programs, as these add formatting data to the files that the ASxxxx Cross Assembler does not understand. So the best choice is to use just a plain text edit or a program such as Atom (link provided below).

Atom is a great little text editor as it allows us to edit all the files in the project folder. We can look at the errors produced when compiling our program beside the Assembly code, which makes it much easier to debug. Atom has a great plugin that will highlight the assembly code in different colours, to make it easier to read. So we can quickly identify what are instructions and what is data?

To help make life easier, I have created a batch file called Make.BAT. The purpose of the file is to compile the assembly program and produce an output file than can be programmed into the ROM of the computer.

As you can see this Make file is very simple. In the first line we just call the as6801 assembler program and pass in a few switch parameters (-xlos), as well as the assembly source file name retro.asm.

The second line of the Make file calls the linker program, where we pass in the output of the assembler program to produce the file we can load into our ROM. We also pass in the name of the linker file which contains the commands for the linker program.

The retro.lnk file just contains the switch parameters for the linker, the name of the input file, the name of the output file and then the end command for the linker.

When we run the MAKE.BAT command, we get a file called retro.s19, which contains the code that the programer will use to program the ROM with this software.

There are a few steps in the process as you can see, but having this MAKE.BAT makes its very simple to produce the file that the programmer can use from the assembly source code.

Below you will find ZIP file which contains the first draft version of the source code (untested), if you want to have a look. This code was pulled from projects that I had developed back in the late 80’s and early 90’s for this Micro.

ASxxxx Cross Assembler

Atom Text Editor


Retro Computer Build Part 3 – Console Port

So far we have discussed getting the Micro operational with the basic control lines, some ROM to hold the firmware, and RAM for the storage of data.

What about communicating directly to the Micro? How are we going to interact with it?

One of the reasons why this Micro was chosen, was because it has a built in UART. A UART is a port, that allows communications to and from another computer in a serial manner (one piece at a time). Serial communications are the most common form of communication methods used for computer to computer communications.

Initially, we will use the console port to interact with the Micro, as its primary interface. Over this interface, we will be able to mentor the internal registers of the Micro, write code, and perform some basic functions that will all help get the Micro operational.

There are different forms of serial communications. Some of these include USB, SATA, ADSL, Wi-Fi, and Ethernet. Each of these have their own advantages and disadvantages and specialised use cases. We will be using the RS232 serial communication on this console port.

In its day RS232 was a very common communication standard (it’s been around since 1962, it’s older than me). It’s not found in many new computers any more, as it has been replaced by USB. To enable RS232 for this Micro, we need to add a transceiver, which will convert the serial signals on the Micro to RS232 compliant levels.

As only some modern PC’s have an RS232 port, we may want to provide an alternative method, to allow communication over USB. If we bring out the serial connections from the Micro to a header, we could then connect this to a TTL to USB transceivers. This  now gives us the ability to plug this USB cable into a USB port on a PC or even an Apple Mac.

This is the approach that I’m thinking of taking, as if I don’t want to communicate over RS232. I could just pop-out the RS232 transceiver and plug in a TTL to USB transceiver into a header on the PCB. Then I could plug the transceiver into a USB port only computer and with a terminal program, I can start talking to the Micro.

We will be adding a full RS232 port to the Micro at a later date, as well as an RS485 port for industrial communications(more on that later in the build).

I plan to use a Maxim MAX222 transceiver, which gives us two transmitter & receiving lines that can be connected to the Micro. We are only going to use one of each of these. We might use the other two unused lines for control signals. The nice thing about this chip is that it has a sleep mode, where the chip will go to sleep when the sleep line is tied low. This device generates both the positive and negative supply rails for the RS232 port.


Retro Computer Build Testing – 01 Control Signals

In the above image, you can see where I have begun to test the control signals on the Micro. An old Thandar Logic Analyser TA100 was used to test these signals. Any modern logic analyser would also work, but I’m trying to keep this retro, or maybe I was just too lazy to plug in a USB logic analyser to my laptop and set it all up. I’ll let you decide.

You can see in the picture that the Micro’s clock E, the Read/Write line and the address strobe line, have been brought out of the Micro. The E and Read/Write line are inputs to the 74HC00 NAND gate logic, which is generating both a Read Enable and Write Enable signal, both of which are active low.

I’ll upload a quick video on these control signals when testing the address decoder logic.

All initial tests pass with no issues. So far so good.