Wednesday, November 15, 2017

Running BASIC

I was able to get BASIC running with out much difficulty once I overcame a bit of confusion with the compiler I was using. First, I started with Z80 Basic by Grant Searle. The only file that needed to be altered was intmini,asm. I made some minor changes to use the TL16C550 UART at 115,200 baud. To get things going quickly, I removed most of the error checking which had more to do with buffer over-runs. I figured, at 115K and my slow typing, I didn't really need them.

As I mentioned, my compiler threw me for a loop. There was a configuration setting I missed that would offset the compiler output by 0x100. The code compiled fine and some of the basic functions worked but the UART interrupt didn't work. Due to the setting in the compiler, all the interrupt vectors were NOP'd and offset by 0x100. The UART would generate the interrupt but, since the vector was a NOP, it would run until 0x100 where the reset vector ended up. It took me longer to figure this one out than it should have..........but I did and BASIC is now running.


Tuesday, August 29, 2017

Added a UART to the Z80

I added a UART to the Z80 board. The original thought was to use a PIC on a separate board to do the UART function but the PIC wasn't quite fast enough. I ended up using a TL16C550 from Texas Instruments and along with a Microchip MCP2200 UART to USB chip. I've used the MCP2200 many times before as finding a 9 pin RS232 COM port on a PC is getting hard these days. I've been able to get UART input and output at 115.2KBaud with no issues.



Z80 CPU with UART Schematic

Friday, August 25, 2017

Programmer Version 2 now in a box

I made a modification to the programmer board and finally got around to building and testing it. All I did was add a 128Kx8 SPI EPROM for program storage. The original programmer worked fine but the Z80 board, since it has no ROM, had to have a program loaded each time it was turned on. With the EPROM on board, depending on the configuration switches, the Z80 will start up as before (Manual mode), or automatically load a RAM image and start running. There is a second switch to indicate which of the 2 images to load. I also ended up putting it into a box with a 5V power supply to make it a bit easier to work with when away from the lab. The Z80 board is mounted on top with the programmer mounted inside.

The box used was from a different project so that is why the location of the AC input is not exactly where I would like it. The front panel switches are as I described. The top has the reset button along with the programmer status LED. Not pictured is the USB connector (on the left side) for the serial port to the PIC on the programmer to communicate with the programmer software.

The programmer software was also modified to allow programming the EPROM or the Z80.


Programmer Version B Schematic

Tuesday, November 1, 2016

Simple I/O Board

I came up with a simple I/O board to implement a test user interface. It is a very basic circuit that will read an 8 position dip switch, write to 8 LEDs, and write to a 2 character, HEX display. The dip switch and LED outputs are very basic items. The HEX display is a little more complex. The display the Steve Ciarcia seemed to prefer was the HP7340. The display had on-board binary to 7-segment HEX (0-F) display logic. Modern displays available at Digikey are around $40 these days. To add the "Modern" component, I used an Altera CPLD to do the decoding and display driving. I ended up using the CPLD to do ALL the logic for the board. Besides the display driver, it has the address decoder, switch input buffer, and the LED output latch. The only other ICs on the board are ULN2804 8-bit Darlington drivers to drive the LED and display outputs.

The address decoder looks at Address bits 4-7 and goes active when the 4 bits match the Address DIP switch setting along with a IORQ signal. Address bits 0 and 1 are used to determine which part of the board is being addressed; The HEX display (0x00), LED output (0x01), or the DIP switch input (0x03).

I used the Altera CPLD (EPM3064ATC100) since I've used them before for other projects and I had a few in the parts bin. I initially decided to use Altera because of their top-notch Quartus II design environment. I was able to do the entire design using the schematic capture feature rather than trying to learn VHDL. If I didn't use a CPLD, I would have been able to use the same circuit (except for the HEX display driver) with discrete components. What makes using a CPLD so useful is the ability to change the design of the board without cut/jumping copper. In fact, I moved various pins around to simplify the PCB layout. When I programmed the CPLD, the switch inputs were responding in reverse order (Switch 0 was being read as switch 7). I had forgotten that I swapped the lines in copper so a simple change in Quartus fixed everything up.


Friday, September 2, 2016

Programmer PC Code

I wrote a simple Visual Basic program to interface to the programmer board. It will take either an Intel HEX file or binary memory image file and send it to the programmer board to program the Z80 RAM. It is not a compiler or any kind of program development system. The basic operation of it is explained in the last post for the Programmer.

Wednesday, August 24, 2016

The Programmer

Programming PROMS, as mentioned earlier, is a total PITA if you don't have a programmer (which I didn't). When designing the Z80 CPU portion, the decision was made to have just RAM rather than RAM and ROM. The interface between the Z80 and the single RAM chip was straightforward. All I have to do to take control of the BUS is to assert BUSRQ and wait for BUSAK from the Z80. Once the Z80 acknowledges the bus request, all its control signals are tri-stated. The programmer can then take control of the MREQ and WR lines to program the RAM chip. Since the lines are tri-stated, I probably could have taken control of them directly but I used a MUX (74HC157) as it will also act as a buffer to the expansion port.

I used a Microchip PIC18F46K22 as the controller on the programmer. This is one of my go-to chips that I know is more than capable to handle the job. I also used the MCP2200 USB to UART chip to connect the programmer to the PC that the code will be developed on. I started using this chip recently to replace the older MAX232 type circuit as newer computers don't have RS232 serial ports on them anymore. An added perk to the MCP2200 is that it also has 8 bits of available I/O that I will use for some simple handshaking. The remaining section of the programmer are address latches.
Since the Z80 is RAM based, there is nothing in memory on power-up so the programmer will always be connected. When the combo is powered up, the PIC immediately puts the Z80 in reset while it configures the bus control circuits to be in-active. The MCP2200 can also be configured to power up with its I/O in a given state. The MODE pin is programmed to power up low and this pin is monitored by the PIC. When MODE is low, the PIC releases the Z80 from reset. It also continues to monitor MODE and the Reset button. If the user presses the reset button, the PIC de-bounces the press and sends a  clean reset signal to the Z80. It will do this indefinitely.

When the PC wants to program the RAM chip, MODE is set high. The PIC will detect this as a request to go into command mode and acknowledge the PC by setting the ACK line high. The Z80 will continue to run as normal.  The PC will issue a Get Bus command and the PIC will assert, BUSRQ, wait for BUSACK, then enable the address latches and switch the control line MUX. The PC will then issue a Set Address command to have the PIC set the address latches to the starting address of where the program is to be loaded. The PC will then start sending 128 byte packets to the PIC containing the programmed data and a checksum byte for error detection. Once all the data is programmed, the PIC will release the programmer bus and control, release BUSRQ, wait for BUSACK to release, then reset the Z80.


The entire 64K address space can be programmed in under 7 seconds.


The programmer.

The programmer and Z80 "married"

Tuesday, August 23, 2016

Some initial design thoughts

As mentioned in the last post, the design I came up with back in the day ended up being across multiple boards and, to an extent, followed what “Build Your Own Z80 Computer” described. There was a discrete clock circuit, a de-bounced reset circuit, the Z80 CPU, a few EPROMs, a few static RAMs, and some address decoder, buffer, and glue logic circuits. It was quite a lot of stuff for just the basic workings of a computer system.

The EPROMs were a huge issue in themselves. First, I didn't have a way to program them. I did build up a circuit to provide the correct voltages and timing but I still had to run everything manually. Imagine having to  set the address on a set of DIP switches, then set the data byte on another set of DIP switches, then press a button that would apply the correct programming pulse. This had to be done for every byte programmed. Miss a bit? Start over! And by starting over, I mean putting the EPROM in the UV eraser (at least I had one of those) for a few hours.

I still don't have a chip programmer but I believe I have come up with a design that eliminate the need for one, at least, directly. The schematic is linked at the end of this post. The design has been simplified as follows. The discrete clock circuit has been replaced by a 2 MHz crystal oscillator (Digikey XC232-ND, $2.98 USD). The Z80 is a standard, 40 pin DIP. The memory will consist of a single 128Kx8 static RAM chip (Digikey 1450-1017-ND, $2.53 USD). There will be no non-volatile storage. There will be an integrated programmer that will load the RAM chip through a USB serial connection. The chip has both an active high and active low enable and that made it extremely easy to interface to the Z80 by using both IORQ an MREQ lines. Since the Z80 only has 64K of memory address space, I will be "wasting" half of the chip but the ease of implementation makes up for it.

I initially had the Z80, RAM, and programmer all on a single board. I ended up splitting the programmer from the CPU section out of convenience. By splitting the circuit, I was able to piggy back the smaller boards onto other orders rather than having to place a unique order for the one board. It's a long story but it works the best for me.

The remainder of the schematic is the interface to the programmer and an expansion port for future I/O.