MS BASIC for the RC2014 6502 CPU Part 2

My last article covered building the cc65 cross-compiler for use with Mac OS X.

Today, I'll go through the details of the source code modifications to build a version of MS BASIC for the 6502 RC2014 system. To recap, you probably want to look at this archeological analysis of MS BASIC for the 6502.

If you haven't seen it yet, I had previously also described the port of Lee Davison's Enhanced BASIC in this article.

My fork of the MS BASIC source code is on GitHub here.

I decided to use the Ohio Scientific (OSI) configuration as the starting point for the adaptation.

defines_osi.c

The first level change is in the defines_osi.s file where you can enable or disable features. You will also customize for your hardware and BIOS entry points here.

I started off using CONFIG_SMALL := 0  to use 9-digit floating point but found it to be very slow. So back to 6-digit floating point instead.

The original OSI BASIC was based on MS BASIC 1. To get the "latest/greatest", I used CONFIG_2A to build for MS BASIC 2.

RAMSTART2 is set to the beginning of usable RAM at $400. Remember that the $300 page is used by the Monitor/Debugger.

Finally, the serial input/output routines (MONRDKEY and MONCOUT) point to the BIOS entry points.

osi.cfg

The osi.cfg file defines where in memory the BASIC will reside.

- BASROM is set to $5000 which is in RAM: I load the binary to RAM for testing. If you are planning to burn the BASIC image into ROM, you will need to set this value to the start address of where the image will be sitting. For example, if you are replacing EhBASIC on a 6502 RC2014 system, you can set the value to $c100 (current EhBASIC start address).
- Unlike EhBASIC, the OSI build of MS BASIC fits under 8KB, so you can change the size from $2400 to $2000

msbasic.s

After setting up osi.cfg and defines_osi.c, I ran an initial build and hit an error. The .feature force_range  was undefined in the version of cc65 that I am using.

Solution: comment out the line!!

loadsave.s

The next errors I hit were the undefined functions: LOAD and SAVE.

In the more customized versions of MS BASIC, a <platform>_loadsave.s file was used to define the LOAD and SAVE routines. This was pulled into the build process in a series of conditional compile statements in the loadsave.s file.

To fix the problem, I added the following:
  .ifdef OSI
  .include "osi_loadsave.s"
  .endif

osi_loadsave.s

And of course I needed to actually write the LOAD/SAVE routines, which were easy to do (!!):

  SAVE:
rts
  LOAD:
rts

While I was doing that, I added a definition for MONISCNTC. This is a routine to check if CTRL-C has been pressed while a BASIC program is running. We call the non-blocking check_input BIOS API at $ff06 and if there is a keypress, check if it is $03.

osi_iscntc.s

Defining MONISCNTC itself did not enable the use of CTRL-C to break a program. I tried porting over Grant Searle's implementation of the ISCNTC routine but that didn't work either.

What worked was a change in osi_iscntc.s to call MONISCNTC as a subroutine vs a jmp. Thus:
 ISCNTC:
 ;        jmp     MONISCNTC
        jsr     MONISCNTC
        nop
        nop
        nop
        nop
        lsr     a
        bcc     RET2
        jsr     GETLN
        cmp     #$03

When I have time, I'll dig into this a little further...

inline.s

The last functional fix was in inline.s to enable the use of the backspace key for editing. I added an OSI build condition to the INLINAIM routine to check for a backspace character.

header.s

Now that I had everything building and actually running, the next step was to make it all easier to use.

There is no fixed entry point to MS BASIC. Every time after making a code change, I had to look in the osi.lbl file to find the address of the COLD_START routine.

On the other hand, the RC2014 Z80 MS BASIC puts the cold start entry point at the start of the binary image. I used the same approach with my port of Enhanced BASIC.

To make this change, I added the following to the header.s file:
    .ifdef OSI
          jmp     COLD_START
          jmp     RESTART
    .endif

The BASIC entry point is now at the start of the BASIC binary image. This is a jmp to the actual cold start entry point. The warm start entry point is 3 bytes after the start of the binary image. This is again a jmp to the actual warm start routine.

Let's talk about the build scripts next.

make.sh

I changed the original make.sh build script to enable a detailed assembly listing of each variant of BASIC.

By default, the script builds for all the platforms. After each platform is built, the resulting bin and lbl files are copied to the tmp directory. The list (msbasic.lst) file is not copied and is overwritten when the next platform is built. The change to make.sh is to also copy the msbasic.lst file to the tmp directory. This makes debugging conditional builds a lot easier.

buildit.sh

This is my top level build script.

Since I am uploading the BASIC binary to RAM for testing, I convert it to Intel Hex format using a bin2hex tool.

The latter is based on a Python library. My fork of that code is here.

Conclusion

The final MS BASIC build file (osi.hex) has been uploaded to GitHub.

Use the Monitor/Debugger to upload it to address $5000, then use the 'G' command to launch it:
     g 5000

When prompted for "MEMORY SIZE?" type in 8192. This will prevent the BASIC initialization routine from clobbering the BASIC code in RAM. If you are running BASIC in ROM, you can just hit <ENTER> at the prompt.

When prompted for "TERMINAL WIDTH?", just hit <ENTER>.

At that point, you will see the Microsoft copyright message.

This is what I get on my terminal emulator:

The key difference with the RC2014 Z80 MS BASIC is that lowercase is not recognized for program keywords and variable names. You have to use uppercase characters.

Enhanced BASIC has the same limitation.

In terms of performance, MS BASIC for the 6502 is almost 0.3 seconds slower than Enhanced BASIC and 1/2 a second slower than Z80 BASIC running the same prime number benchmark.

NEXT

I will build a ROM image with MS BASIC+Monitor/Debugger for the 6502 RC2014 system.

Watch this space!!

MS BASIC for the RC2014 6502 CPU Part 1

The RC2014 ships with Nascom's version of MS BASIC for the Z80.

I have ported Lee Davison's Enhanced BASIC to the 6502 CPU board. As described in my previous article, Enhanced BASIC is really quite fast. A 4MHz 6502 CPU running a prime number benchmark with Enhanced BASIC is almost as fast as a 14.7456MHz Z80 running MS BASIC.

There are several versions of MS BASIC for the 6502 dating from the original Apple 1.

Michael Steil wrote an excellent archeological analysis of MS BASIC in this article. The key point of the article is that you are now able to build an exact replica of MS BASIC for several ancient 6502-based microcomputers.

The complete source code is hosted on GitHub.

The challenge though is that you need to use the cc65 cross-compiler to build the binaries from source.

Apparently, the latest versions of cc65 don't work. Folks have recommended using version 2.13.3. This can be found in several places including this GitHub repository.

If you are a Windows user, Grant Searle has a prebuilt set of binaries here. However, if you are a Mac user, you will have to build cc65-2.13.3 yourself.

Here is how I did it:

• Decompress the cc65 source package to cc65-2.13.3 (you can use another name and substitute accordingly in the following steps)
• Build the cc65 cross-compiler
• cd cc65-2-13.3
• cp make/gcc.mak makefile
• make
• make install

In my next article, I'll talk about how to actually configure and build  MS BASIC.

A 6502 CPU for the RC2014 - Software

Hardware is useless without software. So what software do we have for the 6502 CPU board?

Cross Assembler

The biggest challenge as a Mac user in the ancient computing world is that most cross-development tools for 8-bit microprocessors are for use with Windows (and preferably DOS).

Running VMware Fusion is an option but a relatively expensive one: you need to buy Fusion along with a Windows license.

The other option is running TASM in a DOSbox. But that still requires some work.

Since I am quite lazy, I settled on asmx. This is a multi-CPU cross-assembler (it supports everything from the Z80 to the RCA 1802). The maintainer, Bruce Tomlin, can still be reached by email and has been responsive to my (usually dumb) questions.

The trick to using asmx on a modern OS X computer is the compilation process. Yes, you download the sources and run make on them. By default, make will try to build the old ppc binaries. You'll need to edit the src/Makefile to just compile for i686:

        TARGET_ARCH = -arch i686

Bring up

Once you have designed and built a new CPU board, you need at a minimum some code to make sure that the CPU board is working. You don't want the initial test code to be too complicated because complication = risk of errors.

Fortunately, there is the Real Retro UART Board. This is based on the ancient AY-3-1015 or similar UART devices. Unlike the more modern (that being a relative term) devices like the 6850, Zilog SIO, 16550 and others, the AY-3-1015 is hard configured i.e. you configure the device by wiring up various signal pins. There is no need to write code to initialize the device.

This makes bringing up a new CPU a little easier: there's less new code to write. I generally just write a bunch of 'A' characters to the serial console to show that the new CPU is running correctly. With the 6502, the code will look like:

        reloop
                   ldx   #'A'
    uart_out1                
        lda   uart_status     ; serial port status
        and   #$02            ; is tx buffer empty
        beq   uart_out1       ; no
        stx   uart_xmit           ; put character to Port
        jmp   reloop


Monitor/Debugger

To make a new CPU system minimally usable, you need a Monitor/Debugger. This will allow you to develop and test other software.

An interesting article about the various 6502 monitors can be found here.

For the RC2014 6502 CPU board, I took Daryl Rictor's "lite" monitor and heavily modified it. The key changes are the following:

• Provide the same user interface as the Monitor/Debugger for the Z80
• Implement a BIOS-like approach for console I/O with (a) an externally accessible vector table for console I/O calls and (b) a way to swap in handlers for different types of UARTs
• Resume from breakpoint

The source code can be found here. The ROM images are here.

There are several versions of the Monitor/Debugger, depending on which UART/serial IO board you want to use. If you are using the 16550 board, you'll want to have a 16C550 version of the UART. The 16C550 has the autoflow control feature to automatically toggle the RTS signal without intervention from the 6502. This allows us to run that UART at 115200 baud without overwhelming the 6502.

BASIC

No new RC2014 CPU board is complete without a version of BASIC.

The 6502 has several versions of BASIC available. I decided to start with a port of Lee Davison's Enhanced BASIC.

Lee passed away several years ago and the original source host site is no longer available. A copy of the 2.22 version is hosted on GitHub by Klaus2m5 and can be found here. A discussion forum dedicated to EhBASIC (as it is referred to) is here.

My own fork of EhBASIC is on GitHub here. As usual, I've made some changes:

• Implementation of a SYS function to exit back to the Monitor/Debugger
• Clear cold start and warm start entry points. This is meant to provide a similar user interface as the MS BASIC that is used for the Z80 on the RC2014.
• The use of the BIOS API entry points for console I/O

A pre-build ROM image that combines EhBASIC with the Monitor/Debugger is here. The image is 32KB in size but only the top 16KB is actually used.

The EhBASIC cold start entry point is at $c100 (just above the I/O space) and the warm start entry point is at $c103.

Unlike the RC2014 MS BASIC, EhBASIC only recognizes uppercase (caps) commands/functions. Very retro!

Benchmarks

The Z80 and the 6502 are very different devices.

The Z80 runs four clock cycles to execute the fastest instruction. The 6502 runs just one. The Z80 has more registers and more complex ("dense") instructions compared to the 6502.

Therefore, you cannot compare the Z80 and the 6502 by just looking at the clock speeds.

My estimate is that at a given clock speed, the 6502 is approximately 4 times faster than the Z80. Putting it another way, a 1MHz 6502 runs as fast as a 4MHz Z80. The 7.3728MHz Z80 on the RC2014 is as fast as a 1.8432MHz 6502.

Since we now have a version of BASIC for the 6502, I decided to run a benchmark test. The algorithm used is Robert Sharp's prime number program:

20 PRINT "LIMIT";

30 INPUT L

40 FOR N = 3 TO L

50 FOR D = 2 TO (N-1)

60 IF N/D=INT(N/D) THEN GOTO 100

70 NEXT D

80 PRINT N;

90 GOTO 110

100 PRINT ".";

110 NEXT N

120 END

I ran this on a 14.7456 MHz Z80 (using my Z80 CPU board) and a 4MHz 6502 (using the 6502 board for the RC2014). 

To find all prime numbers to 199, the Z80 gave 10.62 seconds (iPhone stopwatch), whereas the 6502 gave 10.82 seconds.

Which mostly confirms my hypothesis. The Z80 runs slightly denser/more efficient code which makes it a little faster.

Future

I will be doing two things in the near future:

• Port of Peter Jennings' Microchess to the RC2014
• Port of MS BASIC along with an update benchmark - see new article here

I have both working today but checking them into GitHub will require some clean up work... :)

And of course, there is Forth with several versions floating around in the 6502 world.

A 6502 CPU for the RC2014 Part 2b

Readers of Part 2 of this series of articles on getting the 6502 CPU to run on the RC2014 will recall that I was having trouble getting the standard RC2014 Serial I/O module to work reliably.

The latter is based on the Motorola 68B50 ACIA which uses the same bus architecture as the 6502. So compatibility should have been a slam dunk.

That it was not was entirely due to human error: mine.

I had correctly re-wired pin 14 (the E clock pin) of the 68B50 to pin 4 (TX_CLK) which is itself derived from the Phi2 signal of the 6502. All good there.

However, by doing that, I had removed the IORQ signal from the address decoding process! This meant that I was randomly reading and (worst) writing to the 68B50 while read/writing memory!

The 6502 should select the 68B50 only when IORQ was valid.

This is solved by removing the M1 signal from the CS0 pin of the 68B50. Remember that the M1 signal is unique to the Z80. In that world, you want it to be high ("1") to validate any I/O cycle. On the 6502 CPU board, we had tied this to VCC.

Now that the CS0 pin of the 68B50 is available, we can use it with IORQ. The latter is active low while the CS0 is active high. Pin 2 of the 74HCT04 is the inverse of IORQ and can be used directly to validate CS0.

So we keep the 74HCT04 and connect its pin 2 to CS0 (pin 8 of the 68B50).

Voici:

And it all works!!

Conclusion
- If you want to explore the world of the 6502 CPU with a RC2014, you can reuse all the standard modules (RAM, ROM, Serial I/O) with a little bit of re-wiring work.
- All you need is the 6502 CPU board, a 6502 CPU and a number of other easy to get components.

A 6502 CPU for the RC2014 Part 2

Today's article will talk about how to use RC2014 hardware with the 6502 CPU Board aka what is compatible and what is not.

You can go Tor-Eirik's route by using only custom memory and I/O boards to build a Replica 1. Or you can use what you already have (e.g. the boards that come with the RC2014 Full Monty kit).

To start, the following picture shows how we are inverting the Z80 and 6502 memory space as discussed in the last article:

RAM

RAM compatibility is the easiest to deal with.

The original 32KB RAM module works as-is. The entire 32KB is mapped to 0000h-7FFFh in the 6502 address space.

The 64KB RAM module works as long as you either disable or remove the lower 32KB device. This may sound counterintuitive until you consider that we're inverting the A15 signal to flip the upper and lower 32KB memory segments. If you look at this picture, the device to remove is U3 (marked as Start-7FFF). You will want to keep the device marked 8000-FFFF as it will be remapped to 0000h-7FFFh by the inverted A15 signal.

My own Real Retro 3KB RAM board will work as long as you short the JP1 jumpers. The latter will map the RAM from 0000h-0C00h in the 6502 memory space.

My Simple RAM/ROM board will also work. You will want to configure it, if you are inverting A15 on the 6502 CPU board, for ROMLO and RAMHI.

ROM

ROM is a little bit more complicated.

There are currently 2 "standard" ROM modules for the RC2014. I'll ignore the 8K module as I think it's no longer available.

The first module is that one that you'll get with the Full Monty kit. This module/board uses a 27512 ROM and splits the 64KB capacity of the ROM into 8 pages of 8KB each.

The address lines A15, A14 and A13 are used to decode the ROM in memory and 3 jumpers are used to select the page.

If we were to use the module without any modifications, we will map the ROM correctly to the top 32KB memory segment of the 6502 address space. However, the A14 and A13 will only select the ROM when they are low (0) which ends up mapping the ROM page to the lowest 8KB of that 32KB memory segment. Instead, we need the ROM page to be mapped to the highest 8KB in memory.

My solution has been to lift off Pins 1 through 3 of U1 (the 74HCT32), then solder a link from Pin 3 (U1) to ground. See this picture:

The next step is to select the right page in the ROM.

Assuming that you are using one of my ROM images and a 27512 ROM, you will probably only be writing the ROM image to the bottom 32KB of the 27512 ROM.

The 6502 boot code and Monitor/Debugger are located at the top part of the ROM image i.e. in page 3 of the 27512. So you will want to configure the jumpers to select Page 3.

The above applies only if you are using a 27512 device. If you are like me and use a 28C256 32KB EEPROM, you will want to tie the jumpers high (to '1').

The Pageable ROM module/board is a little easier although you will still want to make a wiring change.

The latter is to disable the paging circuitry. I have not tested that circuitry with the 6502. However, I have verified that it will crash an Intel 8085 (my 8085 CPU board for the RC2014). The reason for this is that the paging circuitry does not fully qualify I/O requests (e.g. via the WR or RD signals). So the ROM may be paged out in error.

To disable the paging circuitry, remove U6 (74HC393) and U2 (74HCT138). Then solder a link from pin 3 of the 74HC393 to ground.

If you are using a 27512, you will want to configure for a 32KB page size, then select the lower 32KB page (A15 of the 27512 to ground or '0').

If you are using a 28C256, things get more complicated. You will select a 32KB page size, but leave off the left-most jumper. Then jumper the A14 and A15 lines (in the page selector) to high or '1'. See the following illustration:

Page size:
x x x x x
  | | | |
x x x x x
x x x x x  

Page selection:
x x x x x x
        | |
x x x x x x
x x x x x x

My Simple RAM/ROM board will also work. You will want to configure it, if you are inverting A15 on the 6502 CPU board, for ROMLO and RAMHI.

Serial I/O

Serial I/O on the RC2014 is done by a Motorola 68B50 ACIA. This device is bus compatible with the 6502. However, because of the way it is wired for use with the Z80, compatibility with the 6502 is not straightforward.

At the minimum, the E signal (Pin 14) must be disconnected from IORQ. To do this, you just need to pull the 74HCT04! Then you need to connect E to the CLK line of the RC2014 bus. The easiest way is to Pin 3 or 4 of the 68B50.

Finally, you will want to run the 6502 at a baudrate-friendly frequency. This is because the 6502's Phi2 output is connected to CLK and therefore used to generate the baudrate on the 68B50. I use a 1.8432MHz oscillator.

Now, this setup works. However, it has not worked reliably for me. It is possible that the 68B50 needs the actual R/W signal from the 6502 instead of the RD signal. I'll have to investigate further.

My own UART boards (both 16550 versions and the Real Retro UART) work. The key again, with I/O is to add C000h to the original Z80 port addresses.

Dr Baker's SIO board will likely not work as it uses a Z80-specific device. In any case, I have not tested it.

Other hardware

There are a number of other interesting RC2014 boards but I have not tested them for compatibility with the 6502. I would encourage other folks to check them out and let the community know what works vs doesn't work and/or workarounds/patches.

The RC2014 community itself has gone in many directions as far as add-on boards are concerned. Spencer Owen has graciously compiled a list of RC2014-compatible projects here.

Hopefully, the availability of a 6502 CPU board will spur development in even more directions...!

Next

In my next article, I'll cover software for the 6502.

A 6502 CPU for the RC2014 Part 1

The RC2014 design is based on the Z80 8-bit microprocessor.

As far as 1970s-era microprocessor design is concerned, the Z80 and 6502 are on polar opposites. The Z80 is based on the Intel 8080 whereas the 6502 is based on the Motorola 6800.

The design philosophies are very different:
- The 6800 and 6502 use a strict synchronous bus. Each memory or I/O access cycle completes within a single clock system. The clock signal is also used to gate the read and write control lines to memory and peripherals.
- The 8080 and Z80 use a loosely asynchronous bus where the memory or I/O access cycles take a variable number of clock cycles to complete. The clock signal is not used to gate read/write access. Unless you want to generate wait states for slow peripherals or use Zilog Z80-specific parts (PIO, CTC etc) in your design, you can safely ignore the clock signal.

So how would you go about building a 6502 CPU board for the RC2014 system?

The RC2014 bus was designed in a very similar way to the S100 bus: where the latter is based on the 8080 signals, the RC2014 bus signals are just Z80 signals.

Let's look at each of the Z80 signals and see how we can generate their equivalent from the 6502. We will only consider the signals that are actively used to access memory and I/O. Signals like RFSH, BUSRQ, WAIT, BUSAK, HALT, NMI are not routed on the base RC2014 system and we'll ignore them for now.

M1

Let's start with a signal that we don't care about. The Z80 M1 signal is used with the IORQ signal to indicate an interrupt acknowledge cycle. This is only really used for Z80 peripheral devices like the Z80 PIO, CTC or SIO. Since the 6502 by default grabs interrupt vectors from high memory, we can tie M1 to Vcc.

RD & WR

These are the read and write signals for memory and I/O. The 6502 has a combined signal R/W which is high for read and low for write. In 6502 designs, the R/W is usually gated with the Phi2 clock to generate separate read and write lines. This is what we will do here.

IORQ

The Z80 (and 8080) have a dedicated I/O address space that is separate from memory. The 6502 does not have anything similar. Instead, its I/O address space is part of its 64KB space: what we referred to in more modern terms as memory-mapped I/O.

6502 designs generally carve out part of the 64KB address space for peripherals. We will do this in our design: we will map out a 256-byte address space for use with the RC2014 bus. The IORQ signal will be decoded and active low when this address space is accessed by the 6502 CPU.

MREQ

As far as the 6502 is concerned, anything that is not used by I/O can be considered memory, so we generate the MREQ signal by inverting the IORQ signal.

Schematic

The design that we come up with is as follows:

IC2 is a 74HCT688 that is used to decode the 256-byte I/O space. Its output is IORQ and is also inverted by IC1E to generate MREQ

The RD and WR signals are generated by a pair of NAND gates (IC4A & B) and an inverter (IC1C).

When you look at the design carefully, you will realize that IC1F inverts the A15 signal from the 6502. What is that for?

In addition to the difference in bus design philosophies, the Z80/8080 and 6502/6800 families differ in one critical area. The Z80/8080 place their reset and interrupt vectors in low memory. The first instruction after a reset is fetched from address 0000h. On the other hand, the 6502/6800 place their reset and interrupt vectors at the top of memory. The address of the first instruction after a reset (on the 6502) is fetched from FFFCh.

The result of this is that in Z80 systems like the RC2014, ROM memory is at the bottom of the memory space and RAM memory is placed at the top. The base RC2014 RAM board has its RAM mapped from 8000h-FFFFh, for example. On the other hand, 6502 designs will place RAM at the bottom of memory (starting at 0000h) and ROM at the top (finishing at FFFFh).

Therefore in order to cleanly map a 6502 CPU into a typical RC2014 memory configuration, we invert the A15 signal of the 6502. This essentially flips the memory map around so that the base RC2014 RAM board will be seen as mapping its RAM at 0000h-7FFFh. The RC2014 ROM boards are a little more complicated but can be made to work.

The A15 jumper strip allows you to select whether to use the inverted A15 signal.

I/O Mapping

What about I/O mapping? In our design, the 74HCT688 will decode the I/O space to be between C000h and C0FFh. This means that if you know the Z80 port address of a given peripheral, you can figure out the 6502 address of the peripheral by adding C000h to the port address.

Board design

The next picture shows the final board design:

And the populated board:

Note that the JP1 jumper is needed only if you are using the Western Design Center 65C02. It is used to ground the VPB line.

Eagle design files can be found at GitHub.

Boards can be ordered from OSH Park by clicking on the following icon

The next installment (Part 2) will cover how to use this board with an RC2014 system and will briefly touch on the software.

Building add-on cards for the RC2014

Spencer Owen's RC2014 Z80 microcomputer kit is a great starter platform for learning about digital electronics and microprocessors.

Although the Z80 microprocessor in the design is more than 40 years old, having been introduced in the 1970s, the basic concepts still apply in today's world of Raspberry Pis, Arduinos and smartphones.

The RC2014 is based on Grant Searle's "Z80 Computer on 7 chips". Spencer implemented that design in several modules (CPU, memory, clock, serial i/o) and a number of backplane options. Yes, folks, we have a new industry standard bus!!

This provides for a lot of flexibility. You can swap out the basic set of modules for enhanced versions, for example. Spencer has released new versions of the original RAM, ROM and CPU modules with new features. He has also introduced a Pro version of the backplane that adds the additional Z80 signals that were missing from the original backplane design.

I had worked with digital circuits design in past lives both professionally and as a hobbyist. I had also laid out printed circuit boards. So I took to Eagle like duck to water when I decided to redesign Bernd Ulman's Z80_mini.

For the uninitiated, PCB design is pretty addictive. It's like knitting and solving puzzles at the same time.

As can be expected, I didn't stop with the Z80_mini RevB. I went on to design a new RC2016 UART board and a new/improved Z80 processor card.

The 16550 UART board

The original RC2014 serial i/o module is based on the Motorola 68B50. This part was meant for use with Motorola processors and will work fine with 65xx type processors as well. Its bus interface, particularly the use of a bus clock signal (the E signal), limits its flexibility with other types of processors. That Grant was able to put the 6850 with a Z80 running at 7.3728MHz is testimonial to his genius.

The ancientness of the 6850 ACIA also means that it is a very simple device. Newer UARTs like the 16550 have much better performance in terms of maximum line rate (e.g. 1.5Mbps), bus access speeds and enhanced features like on-chip FIFO that reduces the overhead on the main processor.

The Z80_mini board uses the 16550 UART and I was able to run it at 115200 baudrate along with the Z80 running at 20MHz!

The other nice thing about the 16550 UART is its agnostic nature relative to the type of processor. This opens up the door for the use of other microprocessor families in the RC2014.

The current 16550 UART board for the RC2014 has been tested (altho' usual legal disclaimers will apply). It is available from OSH Park at the link below. The Eagle source files can be found on GitHub. The schematic is here. A BIOS along with the ROM images for Monitor/Debugger with/without BASIC can also be found on GitHub under the source and rom folders respectively.

The default port address ranges used are 80H-FFH. Interrupts are supported. However, I did not use an open-collector driver on the INT signal line. This means that the board is cannot be used in conjunction with other UART boards e.g. the original 68B50 (which also uses port address 80H) or SMBaker's SIO boards. A new board design is in the works to resolve some of these limitations.

Note also that the BIOS will configure the UART for 115200 baud operation assuming a 1.8432MHz oscillator.

Parts used are the following:
- Capacitors: all 0.1uF
- DIP14 oscillator
- 16550 or 16C550, the auto-flow control of the 16C550 is not implemented in software
- 6-pin FTDI pin header, angled. A straight pin version will probably lead to fit problems with other cards on the backplane.
- 74HCT04
- Sockets: 40-pin, 14-pin and I also use one for the oscillator

An enhanced Z80 CPU board

If I have one complaint about the original RC2014 design, is that it is based on a minimum part count philosophy. So there is no power-on reset circuit: you probably have to hit the reset button after connecting power. The processor clock is also used to derive the serial i/o baud rate: this means that it is hard to experiment with different microprocessor speeds e.g if you want to turbo charge the Z80 to run it at 20MHz!

This is one reason why I like the Z80_mini: there's a reset circuit and it is designed for two crystal oscillators: one for the 16550 UART and the other drives the Z80. With the Z80_mini, I can run the Z80 at 20MHz and still get 115200 baud from the UART.

The enhanced Z80 board (branded the "Z80 CPU+") presented here aims to solve both the reset and separate clock issues.

The reset circuit is a standard one with an RC+diode combo and a couple of Schmitt triggers. A pushbutton allows for a manual reset. For those who asked, the diode is to drain the capacitor quickly on power cycle.

The INTR and WAIT signals have pull up resistors. The latter is for an eventual wait state generator in case you want to run the Z80 at 20MHz and still be able to use slow peripherals. A jumper option allows you to connect the oscillator output to the CLK signal on the RC2014 bus.

You can see from the picture that I am running a 20MHz Z80 with a 14.31818MHz clock.

The picture below shows the full set up with a 5-slot backplane:

The Z80 card is on the left, followed by the 64KB RAM module, the 16550 UART card and then the Pageable ROM module on the right. The FTDI cable is connected to the UART card and I am using an external 5V power supply.

You can use the CPU card with all existing RC2014 software.

As usual, the source Eagle files are available on GitHub. Boards can be ordered from OSH Park by clicking on the logos below. The schematic is here.

Parts used are:
- Decoupling capacitors: 0.1uF
- Reset capacitor: 10uF to 22uF
- 1N4148 diode
- 10K resistor for the reset circuitry
- 3.3K resistors for R2, R3
- Z80
- DIP14 Oscillator
- 74HCT14
- Reset switch
- Sockets: 40-pin, 14-pin and 14-pin footprint for the oscillator.

16550 UART board:


Enhanced Z80 board:

RC2014 Pageable ROM with a 28C256 EEPROM

This quick article shows how to configure the RC2014 Pageable ROM module for use with a 28C256 EEPROM.

The RC2014 kit was designed for use with a 27C512 EPROM/ROM device.

If your method of software development is write-burn-test-fail-repeat then a 27C512 device is not for you, even if you were using the EPROM version: UV erase does take a bit of time.

Enter the 28C256 EEPROM device. This 32KB device is electrically erasable and programmable. Which means that if you are at "fail" in your development cycle, just plunk it back into the device programmer and write in a new version of the code (after having electrically erase it, of course, which takes only a few seconds).

Unfortunately, the geniuses who came up with the 28C256 decided to not use a standard (JEDEC) or compatible pin-out. As a result, if you were to compare the 28C256 with its EPROM equivalent, the 27C256, you will find that Pin 1 and 27 are swapped.

In the 28C256, Pin 1 is A14, and Pin 27 has to be tied high (Vcc). This is the reverse of the 27C256.

On my RC2016 Mini, I had to do a rewire.

Fortunately, Spencer designed the Pageable ROM module to be a lot more versatile. And all you need to do is to make sure that the jumpers are set correctly.

The following picture shows the jumper setting I use for "Page Selection". Note that A14 is set to 1 and A15 to 0.

Next is the page size selection. Since I am running the Monitor/Debugger+BASIC, I need a page of 16KB.

The Z80_mini Rev B

I had previously written about how to set up the standard Z80_mini for use with an FTDI-style USB-Serial cable.

This article will describe what else I have done with the Z80_mini.

To recap, the Z80_mini is a little Z80-based single board computer designed by Bernd Ulmann and described in some detail on his website. I like the simplicity, flexibility and completeness of the design, including the use of a 16550 UART, arguably one of the best old-style UARTs out there, a generous use of decoupling capacitors and separate crystal oscillators for the UART baudrate and CPU clock.

Best of all, Bernd has made the Eagle design files available on this website. Which leads to very interesting possibilities.

First of all, I was able to send the .brd file to OSH Park to get myself a set of (3) professionally produced Z80_mini PCBs.

Second, while I was able to, with some minor modifications to the board, adapt it for use with an FTDI USB-serial cable, I could go even further than that.

Eventually, I decided to redesign parts of the Z80_mini PCB. Hence the Z80_mini Rev B!!!

The original Z80_mini is on the right. The redesign Rev B design is on the right.

A picture of an assembled board is below.

The obvious changes are the elimination of (a) the power connector, (b) the circuitry around the MAX232 and serial connector and (c) the addition of the 6-pin FTDI connector.

The less obvious changes are the addition of jumpers to allow the use of 28C256 EEPROMs, a little pin header to bring out the OUT1 and OUT2 signals of the UART e.g. for an audio output perhaps...

The hidden changes involve adding the M1 signal to the UART chipselect, wiring the CTS line to ground (in case a 16C550 is used and we want to run the UART with autoflow control) and of course, routing the RTS signal to the FTDI connector.

Using 74ACT devices, 55ns RAM, 150ns EEPROM and a 20MHz Z80, I've been able to run the board at the full 20MHz spec of the CPU. Instead of Bernd's original 1.8432MHz UART clock, I chose to use a 7.3728MHz clock instead and ran the serial port at 115200 a la RC2014.

This is a very speedy Z80 indeed!

For the adventurous, the Eagle board design files are in GitHub. Z80 assembly language source files are available for a BIOS+Monitor/Debugger+BASIC combo at GitHub. A binary can be found in the rom/ folder if you don't want to muck around with a cross-assembler.

Finally, you can directly order boards at OSH Park with the link below.

Do note that I do not get any money from OSH Park should you decide to order a set of boards through them. The project sharing at OSH Park is primarily so that you don't have to load the .brd files yourself.

The Glitch Works' 8085 Single Board Computer

The Glitch Works' 8085-based Single Board Computer is another one of those cool little projects using ancient technology.

This time, it is the 8-bit 8085 from Intel (although second sourced/copied by a number of other manufacturers). The 8085 is the descendent of the 8080, arguably the microprocessor that kickstarted the personal computer revolution.

The Glitch Works very generously provides the full Eagle board and schematic files for the project via GitHub.

Of course I had to grab them (the rev2 version) and send off the brd file to OSH Park for a set of PCBs.

The design is done the way I like, i.e. relatively conservative with a good use of decoupling capacitors. The ROM circuitry is very configurable: you can use a straight-up 27256-style EPROM or a 28C256 EEPROM (the pin-outs are different). There's even a power-on reset circuit.

A 40-pin connector provides for system expansion. At first glance, I thought that only the I/O ports were available, but Glitch Works pointed out that all I needed was an address latch to get the lower address lines from the data lines. Duh!

I didn't like a couple of things in the design (there's always something, isn't there?), the first is the choice of connection for power (a 0.1" dual pin header) which will require work to use with commonly available power supplies e.g. the ubiquitous 2.1x5.5 barrel plug. The second is the grounding of the 8085's SID signal line.

The latter is one of the nice things of the 8085 vs a lot of other microprocessors of the era. The SID and the companion SOD signals can be easily set up for use as a simple serial port. Of course, it will also be software driven and not very fast.

However, considering that The Glitch Works' 8085 board doesn't come with any other peripheral devices, the availability of both signals would have enabled a real, fully-functional single board computer.

As it is, I had to carefully slice the SID pad to separate it from the ground plane. Then I hacked together a little daughter to provide for an FTDI connector.

The FTDI cable also provides the 5V power supply to the board. Although with a non-CMOS 8085, we are pushing the current-limits of the FTDI cable...!

As you can see in the picture, I am using a real-life ancient ceramic 8085A. This is one that is made by NEC.

Yet another picture:

Ancient hardware is useless without useful and sufficiently ancient software. So I grabbed Donn Stewart's adaptation of Li-Chen Wang's Palo Alto Tiny Basic and adapted it for use with this contraption.

Instead of using a UART for the serial input/output, I use the SID/SOD lines to drive a baud rate of 2400.

This gives us a fully functional 8085 computer without the need for an additional peripheral card. Sweet!

The source code for the Tiny Basic adaptation can be found here. It assumes a crystal of 6.144MHz and 32KB RAM.

Using a FTDI USB-Serial connection with the Z80_mini

The Z80_mini is another minimalist, Grant Searle-style Z80-based single board computer.

Its creator, Bernd Ulmann, was generous enough to make the Eagle PCB files available on his website. I went ahead and had a set (of 3) made with OSH Park.

You can tell that the Z80_mini is a pre-Arduino design: (a) the power supply connector is the type used in PC-era floppy/hard drives, (b) there is a MAX232 and a 10-pin connector for a traditional RS232 interface.

I was able to make a little tweak to use an FTDI-style serial interface along with power routing from the FTDI connector.

The theory behind this is illustrated in the following picture:

As you can see, Pins 11, 12 and 15 of the MAX232 matches the similar signal pins of the typical FTDI header.

So if you were to insert a 6-pin header from pins 10 to 15 of the MAX232 location, you will essentially have an FTDI interface. The following pictures shows how this will look.

The FTDI cable plugs in as shown in the following picture. The GND line is the black one on the right.

If you want to power the Z80_mini board from the FTDI connector, all you need to do is to wire a link from pin 13 of the MAX232 (or pin 3 from the FTDI header) to the nearest VCC signal, for example, on pin 14 of the 74xx14 chip.

The only caveats with this arrangement are:
a. You're not using the RTS line. In fact, this is not connected from the 16550 at all
b. You'll want to make sure that you use low power chips to not overload your FTDI adapter

Otherwise, voila!

I really like the Z80_mini design and will write another blog about what else I've done with it.

16KB ROM on the RC2014

Spencer Owen's RC2014 Mini is a nifty little Z80-based computer.

Spencer ships it with a 64KB ROM containing Grant Searle's BIOS and rendition of MS BASIC. Since the Z80 supports only 64KB of memory space in total, the 64KB ROM is split into 8KB pages. The BIOS+BASIC resides in the bottom-most 8KB page.

I had taken Grant's BIOS, mated it with a heavily modified version of Josh Bensadon's Monitor program and then appended John Kerr's inline disassembler to create the Monitor/Debugger for the RC2014. This all took up close to 3KB of ROM (I used a 32KB AT28C256 device).

MS BASIC would take up close to an additional 8KB of ROM.

So I had to find a way to tweak the RC2014 to decode the ROM space as 16KB pages. In this way, I would be able to fit the Monitor/Debugger plus BASIC into the 16KB space.

This was done in a 4-step process.

Step 1: Lift pins 11, 12, 13 of U1 (74HCT32 on the RC2014 Mini). This will prevent the ROM address decoder from using the A13 line.

Step 2: Remove the S1 jumper. This will leave the A13 pin of the ROM chip available.

Step 3: Flip the board around, and short pins 11 and 12 of U1. We are passing the output signal of the U1C gate to the ROM chip select pin.

Step 4: Wire link from pin 13 to the middle pin of jumper S1. Alternatively, you can wire to pin 26 of the ROM chip (U6). This is to wire the A13 address line from the Z80 CPU to the ROM chip.

And voila, you have now enabled 16KB of ROM space from 0000H to 3FFFH.

The Monitor/Debugger + BASIC ROM image is available from GitHub here. Grab the "monbas.rom" file.

The CPUville Z80 Kit

Donn Stewart's CPUville Z80 kit is another modern day Z80-based microcomputer kit.

You can order just a main board with the processor, monitor in ROM, 2KB of RAM and basic input/output in the form of DIP switches and LEDs. Or you can spring for a serial interface board to load/develop programs. CP/M fans can also go all out and get a disk and memory expansion to run CP/M from compact flash media.

I opted for the main board and serial interface kits but decided to assemble only the main board.

I had started a collection of old Z80 processors; different models (2.5MHz vs 4MHz vs CMOS) from the different manufacturers (SGS, Sharp, NEC etc). However, I had no way of testing my collection. In today's world, one can find almost everything on Ebay but not everything you do find is genuine.

The CPUville kit with it's bank of LEDs is just the ticket for a low cost ($42+shipping) Z80 tester.

The picture below shows an SGS Z80 being run through its paces. Note that I am using a ZIF socket so that I can swap out the 40-pin CPU.

The test program is a basic loop that increments the HL register, then displays its contents on the LEDs. To make this perceptible to human senses, the A register is decremented from 255 to 0 before incrementing the HL register.

So far all the Z80 CPUs in my collection are good!

But what about the CPUville kit itself?

I generally like the concept of the board. The board and parts are of good quality with buffers for the address, data and control lines which the RC2014 lacks (@spencer, hint hint).

Unlike the more "modern" Grant Searle-inspired designs, Donn went with 74LS TTL parts. I, of course, substituted 74HCT parts for lower power. The only downside there is that Donn's low frequency RC clock generator does not work with the 74HCT04. I'll probably put the 74LS04 part back.

Donn did not supply IC sockets for all the chips, but I used them anyway: partly paranoia, partly general hygiene.

Speaking of hygiene, the only thing that disturbs me about the CPUville board in general is the almost total lack of decoupling capacitors!

As someone who actually worked on 70s/80s-era microprocessors and TTL design, I was quite floored by this. So I added a couple of them. At least, one 0.1uF at the crystal oscillator, and one across the power rails of the Z80 itself.

The main board has some of the CPU signals brought out to two 16-pin IC sockets for expansion (the aforementioned disk/memory expansion and serial port card). So there are options available for a more complicated setup. One CPU line missing from the expansion sockets is the interrupt line.

The only roadblock I hit when putting together the board comes from a silkscreen error on the board. The silkscreen footprint for the 2 network resistors was reversed. To his credit, Donn points this out in his very well written manual. To my discredit, I didn't RTFM before assembly.

As a result, the input ports did not work and I wasn't able to use the monitor program. The latter, in a very nice way, uses the input DIP switches as user inputs to select which built-in monitor program to run.

Fortunately, I had a couple of 28C16 EEPROMs (they're a plug-in replacement for the 2716) and so wrote my own test code that by-passed the program selection: upon reset, my code would just immediately run the LED sequencer.

I've a couple of replacement network resistors on order with Jameco and will fix the problem when they arrive.

Otherwise, it was a fun little project!

The RC2014

Spencer Owen's RC2014 is another Z80-based microcomputer in kit form.

There are two versions of the RC2014: a single board version called RC2014, and the original RC2014 which is based on a motherboard with several plug-in cards.

User interface is via a serial console and supports color text via ANSI terminal emulation. I am using an FTDI USB-Serial cable and a serial terminal emulator software, aptly named Serial, on the Mac OS X.

I bought one of each version of the RC2014 and decided to build the single board one first since it required less soldering and was more compact.

As you can see from the newer picture below, I have been doing "stuff" with it.

The RC2014 comes with a version of Microsoft BASIC in ROM. If you want to do anything with assembly language, you are mostly out of luck: it is rather onerous to upload cross-assembled Z80 code from a PC or Mac.

Enter the monitor program from Lee Hart's Z80 Membership Card. It is written by Josh Bensadon with contributions from various other folks. The monitor is provides a serial console interface and is able to drive the Membership Card hex display/keypad front panel.

I took the source code, removed all the hex display/keypad code, adapted console code to work with the RC2014's 68B50 ACIA/UART, added breakpoint support and voila, we now have a Monitor/Debugger for the RC2014!

The modified source code is hosted on Github.

The really nice thing about Josh's original monitor is that it allows you to upload Intel HEX formatted binary files. So developing on the RC2014 becomes a question of write->assemble->upload->run. And all this without the need for an EPROM programmer or other hacks/workarounds.

I had to make a number of tweaks to get the Intel HEX uploader to work well on the RC2014 and it is robust enough now to upload the whole monitor program itself into RAM for additional development. This is actually how the breakpoint code was developed.

The little plug-in card you see on the right of the RC2014 Mini motherboard is a 16KB RAM card. The original RAM on the RC2014 sits from 8000H to FFFFH. BASIC uses memory in this space. The 16KB RAM sits at 4000H-7FFFH and can be used for further development of BASIC, without colliding with the latter's dependencies.

Lee Hart's Z80 Membership Card

I bought Lee's Z80 Membership Card as a kit more than a year ago but only just got around to building it.

Instead of trying to build it to fit in an Altoids can as originally designed by Lee, I decided to make the build a little bit more versatile for future expansion and used Arduino-style connectors to enable stacking additional cards below the CPU board.

It's a good thing I did as Lee is working on a Serial/RAM/SD-card board that will allow this little gem to run CP/M!

Along the way, I also discovered the joys of FTDI USB-Serial mini-boards. Yay! No more RS232 voltage converters! And painless serial console from my Mac.

My other touches of "customizations" include IC sockets for the TTL chips and a barrel socket for an external 5V power supply for when the FTDI is not being used. When the FTDI board is used, a short across pins 19 and 20 of J2 connects VIN to VCC, thus powering the whole setup from the USB port of the Mac.

kswichit's 8080 Microprocessor kit

Ordered through Ebay. It took forever (>1 month) to get delivered thanks to US customs.

The 7805 voltage regulator did not have a heatsink: bad design. Fixed.