Hello,

With the use of toggle switches, you can immediately see wich is a 1 and wich is 0.
I have worked with a system that used toggle switches to enter a start program, that would read the paper tape.

Bertus

The TI 960B had toggle switches on the front panel. You had to key in boot code to boot the card reader and that booted the harddrive. I could key in the multi step boot code in a matter of seconds. I would amaze some of my co-workers.

 

In the 1980's there was a thing called Z80 MicroProfessor that worked sort of similar.
You could input hex codes for each address then increment address.
Then you could run your code.
It had LED's and switched that you could read/write to.

 

In the 1980's there was a thing called Z80 MicroProfessor that worked sort of similar.
You could input hex codes for each address then increment address.
Then you could run your code.
It had LED's and switched that you could read/write to.

Yes. In the '80s there was all sorts of Z80 stuff...

I do miss the old days.

 

The first micro I played with was COSMAC 1802 based and had a front panel that had a set of toggle switches and a push button to load the data. One of the great things about the 1802 was you could load the monitor program without any other firmware by setting the data lines and then driving a line high. So before getting started you needed to load around 200 instructions via the toggle switches (no errors allowed),

Looks really nice but +1 for toggle switches

 

Here is the latest schematic for the motherboard.

Just in case the image does not work (it is an svg):
http://postimg.org/image/pn7ntfp4f/full/

 

Great project, lots of fun writing z80m assembler, not so many years ago. Out of curiosity, which variant of the z80 are you going to use?
The reason I ask, I've recently bought some 20MHz cmos z80s from either rapid or rs cant remember which. But they are the same 40pin package, and cant wait to see what they're capable of.

 

Hi all,

So it has been a few weeks and much of the project has changed!
Individual small cards for the IO board where scrapped because I recently purchased these strip boards from china (10 of them), and they are THE BEST thing I have EVER used for proto-typing!

The computer is still made with individual cards with a bus that essentially takes the pinout of the Z80 so that the computer is expandable. Currently there are three cards, the CPU and internal controls, the memory and the IO which controls a hex keypad with function keys and an 8 digit led display.
The button idea is being put on hold for now because there where too many parts to wire up. I also chose to go down the path of a hex keypad as someone else here mentioned because it makes code entering easier.
Indication LEDs will be included in the future but for now I am more interested in getting a paper tape reader, I2C solid state memory, RTC, serial port, graphics card (256 x 128) and other IO working.

So where am I now? Take a look

The display driver has been written and works very well! The keypad system still need writing and will begin today.
Here is a side view of the machine:

I plan to fit this into a case at some point but now, hardware is more important.

Major Changes

There has been a major change to the interrupt system because there was a mistake in the original design. There exists a timer that fires around 20 - 30 times a second for display updates. Now originally I connected this through an OR gate so that external interrupts could also share the signal. However there lies an issue

The Z80 interrupt system samples the pin and is not triggered. My timer is a square wave with 50% duty cycle. That means that once the interrupt is fired the computer will update the display and get stuck for 50% of the time (as the INT signal is being held low for 50% of the square wave). The solution was to include a flip flop that gets clocked by the timer and the flip flop output connect to the Z80 INT line. The reset to this flip flop is from a NOR gate with its inputs connected to IORQ and M1. These signals are both low when an INT signal is acknowledged. When the interrupt routine is finished the computer runs like normal. Since the flip flop is edge triggered the holding of the clock line low does not re-trigger and thus the system now only updates the display on the FALLING edge of the timer.

 

Here is the bootloader card current underworks. Comes with rounded edges

 

Hi all,

So I was supposed to stick to a design but during the programming of the computer an unfixable error occurred. Despite the fact that there where no floating inputs and all inputs either tied or used there was a problem with the keyport that meant it never worked correctly and caused frequent system errors. I spent a number of solid days trying to fix it but getting no where so I decided to throw in the towel and brought in the big guns, a PIC18F45K22 based IO card.

While designing the new IO card I realised that a useful computer will be more rewarding than a simple blinking lights machine so this computer now has the following (and is working)

• BIOS with system calls (RST instructions)
• PS/2 Keyboard
• UART
• I2C Memory
• Composite Video Output
• ROM Chip now sits in a ZIF socket
• Boots over I2C

What needs doing now? Well, I intend to write an inbuilt assembler, design a BASIC system, get a FAT going and far future...wifi.

All the best,
Robin

 

Hi all,

4 months into the project and here is where I currently am:

• MicroFAT (a file system I have designed), is taking shape and can now do most file functions (just need to make a write and read stream)
• DOS commands are working well (this version of DOS is a homebrew and called uDOS)
• Using SDCC I can now compile programs to run ontop of uDOS written in C
• uDOS is written in assembler
• I2C drives can now be accessed using the microFAT system. Commands include
  1. dir - make a directory
  2. new - make a new file
  3. del - delete a file
  4. cd - change directory
  5. up - moves up one directory
  6. run - runs a file
  7. bitmap - super duper secret function that dumps the bitmap table (tells you which blocks in the file system are in use)
• The computer can boot either through I2C or UART via FTDI. But as changes have been made the UART boot is not working (but did for a while)

 

A quick note on the BIOS that I think some users may find interesting:

OS API

My BIOS is growing quite well and provides very useful features for any program running on the machine. But there was one issue, how do I make a program to run on-top of my operating system so that it can access the OS special features (such as read/write to file)? The answer was software interrupts (RST) but it had limitations.

The RST is hard coded in ROM and sits at the bottom where as the OS is booted into RAM (and does not sit within the RST table location). If I dedicated an RST for API reasons it would require that the RST jump location is hard-coded (not good for relocatable code). But there is one instruction that allows me to avoid this completely, JP (HL).

This will jump to the location pointed by the register pair HL and therefore HL could contain the API handler. However, this would use up HL (a very useful register), and therefore not very useful. But wait... there are other RST instructions. So here is how you avoid the use of any register AND get an RST to jump anywhere:

This instruction will load a variable held in the RAM (located in the special variable area for BIOS function) that points to where the OS API handler is. For example,. if the OS handler code is moved and the location of the API is now at 0x8050, nnnn just needs to have that value. This code is executed once when the computer boots the OS.

ld hl, nnnn
ld a, 0xF0
rst 08

Then when the user in his/her program call the following API RST....

ld a, nn     (nn refers to the specific API instruction, common in most software interrupts)
rst 20

This is executed by the BIOS at 0x0020

push hl
ld hl, (rstLocationVariable)
jp (hl)

The only catch is that the first instruction the API should execute is a pop hl so that the stack is fixed and the value of HL is restored.

 

Hi Robin , Impressive work indeed , Like others here I had great fun with Z80 back in the 80's , before that an RCA1802 on a DIY etched board , with eventually dual 5 1/4 floppies . My venture into the Z80 world was a Maplin Dev Bd, I was learning to play the Organ, an Elka E19 but wanted more sounds, so I MiDi-fied the 2 x 66 note keyboards, (I 'stole' the timing data from its 8085 controller, 5 msec to scan all the keys , turn key map into keys up / down decode the numbers to MiDi channels with velocity and volume and transmit to a Yamaha TG100, a sound with box 100's of voices, I had a dos based assembler for Z80 , and when I needed more styles and voices I turned to PIC , next was a dual PIC16F877 and a Yamaha QY700 , Z80 is still interesting to me , but seems to have no great following...

http://www.eevblog.com/forum/microcontrollers/another-z80-computer-build/msg1012509/#msg1012509
(22swg )

 

It reminds me a lot of the 1980's Z80 Micro-professor.
That had an LED display with a keyboard and you could input Z80 code in hex.

 

Robin, I see your 8 bits and raise you 8 bits . Mid 1970's got trained on the companies mini 16 bit system M605 all TTL whizzing along at ~1 Meg , this was the test panel ... ( rainbow cable goes to card with 80 TTL chips on )