16450 UART testing

Today I`ve connected a standard 16450 UART (NS16450N from National Semiconductors) to my Z80 computer . The connections and chip operations proved to be really easy.  Before I start the breadboarding I was concerned about the chip count I would need to use in order to run this thing: the UART chip uses a logic “1” for active RESET and INT signals, so it means that I have to use 74xx04 hex inverter besides 74xx32 or 74xx138 ICs for address and control signals decoding. However, thanks to additional chip select pins on the 16450 and additional address decoder on the C-Z80 expansion board I was able to use only 74xx04 for address decoding, chip activation and also RESET and INT signals inversion. Here is how it`s done:

C-Z80 System                         NS16450 UART

A7 ————————————– CS0

A6 ————–|>o——————– CS1

/IOREQ+NAND(A8-A15) ———— /CS2

/RESET ————-|>o ————– MR

/INT —————-o<|—————- INTR

This circuit places the UART in I/O address space ff80h – ff87h (it also uses A0-A2 for it`s internal registers addressing) and takes care of proper RESET and INT signals logic levels (Interrupts are not used in the tests, but I plan to enable them as an option)

For the test purpose I didn`t connected MAX232 circuit for voltage level conversion, but instead I used my handy RS232-to-TTL converter connected to PC`s COM1 port.

Here is a picture of the whole circuit on a breadboard connected to expansion port on the computer:


Based on the information from the NS16450 datasheet, I`ve issued a set of commands from the ROM Monitor which caused the UART to send three bytes to PC with Teraterm runing. Here are the commands with description:

output ff83 83

; Sending ‘10000011’ to Line Control register: sets the 8bit data 1bit stop , no parity check operation. It also enables the Divisor Latch registers to be accessible.

output ff80 0c

output ff80 00

; Sets the Divisor Latch registers to value 12 (dec). According to datasheet, this value sets the baudrate to 9600 bps when using 1.8432Mhz crystal (which is the one I`m using)

output ff83 03

;Exiting the Divisor Latch mode and returning to normal operation, keeping the previously selected mode of operation.

output ff80 41

output ff80 42

output ff80 43

;These commands send the “ABC” string to Transmitter Holding Register, and therefore to the PC.  On the PC side we can see the results:


For the receiver test I`ve been pressing the “d”, “e” ,”f” keys on the PC and after each keypress I`ve been doing an input operation  from the receiver buffer (ff80h – the same address as the Transmitter Holding Register) on the C-Z80 side. The effect is shown below (there are also previously tested output commands visible on the screen):


Hex “d”, “e”, “f” ASCII characters are read from the Receiver Buffer.

It was extremally easy to test the UART when the ROM Monitor and it`s functions were available – I haven`t even used a single assembler instruction for this: built in input/output commands and keyboard/screen subroutines in ROM were all that I needed. Now the circuit is ready to be taken trough the Eagle Layout Editor to the PCB board and plugged to the C-Z80 expansion board.

For the tests I`ve beed using information from NS16450N datasheet, avalable at:


and I`ve also taken some hints from Thomas Scherrer website:



ROM Monitor version 1.0 ready !

I`ve managed to run the initial version of the ROM Monitor program and placed it in FLASH memory. Here is a list of available commands:

dump: Memory dump from a given address
edit: Memory editor.
fill: Filling the memory with fixed content.
copy: Copying one part of the memory to a different location
cls:  Clearing the screen.
input: reading a byte from I/O port
output: sending out a byte to I/O port
jump: Jump to given address.
load: loading data/code to RAM memory trough bootloader board connected to input port on the motherboard.

Below you can watch a youtube presentation of the system. Check it out !


The sound board – final corrections.


, , ,

I`ve managed to run the LM386 amplifier on the sound board. The problem was probably in lack of deglitching caps by power pinf of hte ICs used in the assembled version. After adding those caps, the amplifier just started to work as it should be. Hovewer, I `ve experienced some more problems with CLK signal generator. I couldn`t choose R and C values needed for proper operation. Finally I ditched the circruit and repaced it with 1Mhz crystal generator on the back of the PCB. It doesn`t look as good as the original version, but it is solid, and works perfect. All the basic functions of AY-3-8912 were checked with some simple Z80 assembler code. The amplifier, speaker and volume regulation also worked fine this time.

The actual setup for the moment, with all the components made so far:


The sound board (continued …)


, , , , ,

The sound board is assembled and working. For tests I`ve written a simple program that generates a different  tone for each of the three channels. There was a small problem with  cap value (the one used in CLK signal generator).  Measurment indicates 2.4Mhz frequency, acceptable value, but near the top 2.5Mhz value from the datasheet. If the cap value isn`t properly choosen, the signal fill rate gets out of specs (40-60% range nominal) and the AY chip doesn`t work. I`ve managed to pick a value of 560pF, which gave me a stable signal of about 2Mhz frequency and acceptable fill rate.

Whats more – LM386 amplifier refuses to work. I`ve tested the card in line-out mode this time. In meantime I`ll check the cause of the problem.

Photos of the assembled module:

ay_back ay_front

For now I have to lay aside the plans of building more expansion boards (RS232, Z80 CTC board) and focus on the development of the ROM Monitor program. The design must be carefully planned, as the decisions made here will have impact on the future form of the system. For start I`ll use partialy written routines for keyboard readout. I have to decide on some variable handling procedures, stack usage, etc. The program and all it`s subroutines code should of course be heavily commented.

The sound board.


, , , , , ,

I`ve decided to quickly design an ay-3-8912 based sound board for the computer. I have two pieces of the chip, one is used in ZX Spectrum AY-board , the other I`ll use for my own project. The design is a modified ZX Spectrum AY interface. I`ve made some necessary modifications: a different address decoder and clock source. My circuit is based on a “MELODIK” interface seen on the net. There is an opion of using internal LM386 based amplifier  (mono, there are goldpin connectors for speaker and volume potentiometer) or direct stereo output: the selection is made using jumpers. I`ll probably stick with amplified mono output though.

The board uses 2 I/O adresses:

1111111101111111b (FF7Fh) :

read mode: check the contents of currently selected register.

write mode: selection of active register (it`s address will be latched internally in AY-3-8912 after this operation)

1111111101111110b (FF7Eh):

write mode: Writes new value in a currently selected register.

The device decodes /IOSEL+/IORQ, /WR /RD and A7=0 + A6=1 signals. Function select is made by A0 line.

Below are schematics and board layout design in Eagle. The board isn`t even etched yet, but I hope the design is OK, and the board will work without problems.

music_brd music_schematic

The video board.


, , , , ,

Today I finally managed to transfer the prototype of the video board to target PCB. The design was made in Eagle as usual. The traces layout was printed on a laser printer and transfered using an ordinary iron. The boarw was etched in B327. During the initial run of the board a problem came out: a black screen on the monitor connected to it. A logic probe connected to the VGA socket revealed that there were no vertical pulses at all. After checking the solderings I found out that pin no. 35 of XC9536XL was floating unsoldered. After fixing it, the whole system started and worked perfectly. Below you can see the schematics ,  board layout design I made and of course the assembled board and the whole system running some tests:






Below is a photo of a complete set up to this day. Plans for the future ? To start the development of a ROM Monitor program, and some experiments with AY-3-8912 sound generator chip.


Early sketch of the motherboard.


, , , , ,

While going trough some papers recently, I`ve found a very early sketch of the motherboard design I made back in Febuary. There are all the basic components on the sketch that are now on the final version of the board. The purpose of the sketch was to determine the optimal position of all components to be placed on the PCB along with all the buses , power and other signal traces. Especially the RAM/ROM and I/O decoder solution suggested here proved to be useful, so now I`m using it it the final version.


The video board: a possibility of software hack!


, ,

The prototype of the video board is working great. However, during some tests I found out, that there may be an easy way to implement a simple graphics mode in addition to normal text mode for which the module was designed. The original version of the macro used in AVR source code keeps displaying 8-bit wide chunks of ASCII characters stored in FLASH memory. The contents of RAM decides which character is to be displayed at current position (bytes in RAM are essentialy indexes for bitmap font tables in FLASH). If we use the contents of RAM without decoding it trough lookup tables in FLASH but just displaying them directly on the screen, we`ll get a simple way of displaying bitmap graphics ! Of course the AVR code has to be upgraded with some new routines, but it wouldn`t be too hard, as new code will require just some minor changes and timming adjustments. First of all, there should be some switching mechanism implemented in the Atmega that will toggle it`s operation between text and graphics. In the graphics mode it will differently interpret the input data from Z80 and place it in RAM. The display routines should be faster, as there will be no FLASH access at all. I`ll probably use the video RAM space over the screen buffer for implementing communication between AVR and Z80, as mentoined in earlier posts. The 2K SRAM built into Atmega328 will theoretically allow to use graphics resolution of 160×100 pixels. Seems not very much, but you could see some example uses of a special CGA mode in early PCs. It is exactly 160×100 (with some colors too, but that`s not the point ..), check out how nice it looks !


System Bus Pinout


, , , ,

This is the computer`s bus signals pinout. The connector is 40 + 3 goldpin female.

40 +3.3V
39 A0
38 A1
37 A2
36 A3
35 A4
34 A5
33 A6
32 A7
31 A8
30 A9
29 A10
28 A11
27 A12
26 A13
25 A14
24 A15
23 CLK
22 D4
21 D3
20 D5
19 D6
18 +5V
17 D2
16 D7
15 D0
14 D1
13 /INT
12 /NMI
11 /HALT
10 /MREQ
8 /RD
7 /WR
2 /M1
2 /NAND(A8-A15)
1 NAND(A8-A15)

VGA Board prototype finished and working.


, , ,

The VGA board prototype is finished now – including parallell to serial interface. The biggest problem – synchronization between Z80 writes and Atmega reading was resolved using 7474 flip-flop as planned before. Atmega328 source code in assembler is available upon request.

The final version of the video board is capable of displaying 40×33 characters using 8×12 pixel font. The interface of this board takes  X and Y coordinates and 8 bit data (ascii). A single write of a character to the screen requires only one assembler instruction with three parameters:

ld b, 32        ;Y – max. 32

ld c, 39        ; X – max. 39

ld a,65        ;ASCII code is placed in A register here

out ( C ), A    ;Display the character at given position.

The VGA board converts the parallell data to serial signals, and places the data into video memory inside AVR chip. This process takes place during 2 horizontal blanking times (1st. blanking: readout of X and Y coordinates, 2nd blanking: shifting in the ASCII data). 74LS32 and 74HCT74 are producing /WAIT signal for the CPU, which prevents it from writing new data before actual is processed.

The results of initial tests showed that troughput of the video board interface is surprisingly high. It seems that there will be no need for special AVR code routines to speed some operations like filling the screen, clearing it , copying/moving data, etc. Everything can be done in Z80 code using simple I/O writes to video board registers. However, there is still a possibility to implement some sort of command list for the video controller: Suggessted way od implementing it is to use the video memory area just above the video buffer for writing commands and additional data. AVR could execute given commands and manage the command buffer during the vertical blanking period. However, there is a little problem with this solution: If , let`s say, a “clear screen” command would be issued at the start of a frame, and some time later there would be some writes to video memory, the result will be that those writes would be wiped out by the earlier issued command during the vertical blanking time. The easiest way to prevent this would be to insert a ~1/70 second delay after issuing the command, to ensure proper execution. It could also be useful t generate a /WAIT signal for the CPU , just like in a regular write operation (but for a longer period – to the end of the frame)

The prototype during operation:


A sketch of the circuit drawn just from the prototype board: