CTC Board ready. Future plans.

Assembly of the CTC board is completed. I`ve added a jumper for disabling interrupt signal if needed, and I`ve also placed a goldpin header with output and input  signals from the CTC:

Channel 0: ZC/TC0 / CLK/TRG0

Channel 1: ZC/TC1 / CLK/TRG1

Channel 2: ZC/TC2 / CLK/TRG2

Channel 3: CLK/TRG2

This header will be available for any peripheral device in the system. It can also be used for cascading  output from one channel to another inside the CTC itself.

ctc_system 004ctc_system 005

Circuit schematics and board layout design:


Below We can see the whole system as it looks today. Four expansion cards are visible. From left to right: CTC board, UART Board, VGA display board and sound board:

ctc_system 003

Most of the hardware of my computer is now ready. I only have to decide on the mass storage solution. Also I`m still planning to add an I2C controller to take advantage of some interesting peripherals like RTC clock, EEPROMs, etc.  In near future I`ll focus on the programming side of the project for a change. I`m going to add some UART routines (including data/program downloading / uploading ) and test some CTC interrupt functionality. I`ll try to write some form of “sound system” which could allow me to play music in the background using interrupts from CTC. I`m also planning to update the VGA Display board`s firmware to enable graphics mode of 160×100 pixels.


UART Board ready, CTC testing

Today I`ve completed the UART board, here are the photos of the PCB:

ctc-uart 004 ctc-uart 005

I was wondering about the interrupt functionality of 16450. I  haven`t really planned to use it, and was going to disable it for good in the final version of the PCB.However, I`ve decided to leave a possibility to use the interrupts in the future by adding jumpers which allows me to select /INT /NMI or NONE.

Schematics and PCB design are below:


A Z80CTC chip was also tested today. I`m planning to use the CTC`s interrupt functionality extensvely in C-Z80, so this IC will be connected to /INT pin of the system bus.  The connections were rather straightforward , and besides the CTC I`ve only used 74HCT32 for address decoding. The decoder produces a logical OR between A6,A7 and NAND(A8-A15). Lines A0 an A1 are connected to CS0 and CS1 of the CTC. This setup places the CTC in address range of  ff00h to ff03h. The test circuit is shown below:

ctc-uart 003

The logic probe seen on the upper part of the screen is connected to ZC/TO output pins of channed 0, 1 and 2.  After programming the CTC with folowing commands:

ctc-uart 002

Which starts channells 0,1,2 in timer modes with prescalers of 256 and time constants of ffh, 80h and 40h I observed these waveforms on ZC/TO pins:


The period between pulses on channel 0 is about 16ms , on channel 1 – 8ms and on channel 2 – about 4ms.  The chip seems to be working fine. Interrupts haven`t been checked yet, but there is no reason they shouldn`t be working also. The CTC will be working with Z80 in interrput mode 2. At this moment I`m not planning to use other interrupt capable devices besides earlier mentoined 16450 which could work on NMI if I would need serial port interrputs  badly.

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 !