While I was messing about with the PZ80 schematics, I realized that I really needed an environment where I could write and run test code for the ROM monitor before I went burning EEPROMs. I searched around for a few days for a suitable machine emulator, but ran into severe bugs with those that I found that weren't tailor made as CP/M emulators.
While I was searching around, I came across the website of Marat Fayzullin, who wrote a fantastic HOWTO on writing computer emulators:
http://fms.komkon.org/EMUL8/HOWTO.html
The PZ80emu is far from complete, but so far is able to load ROMs compiled by z80asm on my Mac. It executes them quite well from what I tell, as long as I don't use any of the instructions I haven't implemented yet. I have also implemented a very basic NCurses interface, mostly because I've never coded with NCurses before and thought it would be fun.
The code is most definitely alpha, and is incomplete, but anyone interested in hacking on what I've got so far is more than welcome. I will certainly keep the Git repository up to date as I hack on the code, and will gladly accept pull requests.
https://github.com/protoCall7/PZ80emu
Tuesday, June 16, 2015
Sunday, June 14, 2015
PZ80 - Taking Another Step Back
After re-designing the bus buffering on the Z80, the project kind of stalled for me. I ordered some parts now and again, and tweaked the schematics, but didn't make a whole lot of progress.
Feeling that this was an unacceptable state of affairs, I decided to take a step backwards and simplify my circuit. What I would up with was the Z80 being fed with power from my bench supply, the entire data bus pulled low with 1K resistors, a few pull-up/down resistors on the control lines, and the oscillator. Once that was set up, I connected my handy-dandy OpenBench Logic Analyzer up to the first 7 bits of the address bus, and to the clock signal, and fired everything up:
Admittedly, it didn't look like that on the first shot, but after some troubleshooting, it turned out to be user error in the configuration of the logic analyzer, not in the board itself.
The pattern above is caused by the address bus doing a binary countup. The Z80 instruction set has the NOP instruction as 0x00. By pulling the entire data bus low and resetting the CPU, the machine will start at address 0x0000, read a "NOP" from the data bus, increment the counter to 0x0001, read another "NOP", and repeat. Since the current address in the program counter is displayed in binary on the address bus, the logic analyzer displays the above pattern when the board runs.
As far as farther incarnations of the design, I have decided to temporarily build a "MK1" type design, utilizing 32k of ROM and 32k of RAM. It will use an SIO and a MAX-232 for serial communication, and I would like to work on implementing an IDE interface using CF storage (but this might wait). This design won't be adequate to run CP/M, but will give me a working platform to start developing the ROM monitor, which will be an integral part of boot loading CP/M in the MK2 design, which would integrate a memory bank switching scheme to swap the ROM out for a 32k RAM chip as a part of the CP/M load process.
I haven't yet decided whether to implement the Z80-CTC for interrupt control + Z80-SIO timing in the MK1 design, or just use another full can oscillator to give a fixed serial baud rate, but I will be going with one of those two methods.
In the mean time, I have been working on putting together a machine emulator in C, as I haven't found anything suitable to write and debug my ROM monitor with, but that's a subject for another post.
One last note, I finally decided on a name - The PZ80!
One last note, I finally decided on a name - The PZ80!
Friday, June 12, 2015
Commodore Build
A few months back, I ran across a post over at Hackaday telling the story of a Kickstarter trying to put the original C64 injection molds back into production making enclosures.
http://hackaday.com/2015/03/11/hackaday-retro-edition-a-new-commodore-64-case/
I never had the pleasure of owning a C64, but I always wanted to play around with one, especially with some of the MIDI sequencer software floating around. I couldn't help myself, and decided to back the Kickstarter and get one of the enclosures. After hearing a horror story about a factory fire from the Kickstarter update, I started to doubt that the enclosure would ever show up... Until today today, when I received a mysterious package containing...
I am still working on sourcing a board, but I have a line on several non-functional ones. I'm hoping that with a couple bad boards, the original schematics, and some soldering iron time, that I can cobble together a working C64. Having the enclosures sitting here certainly makes the project feel more likely to actually happen. Stay tuned for more updates!
http://hackaday.com/2015/03/11/hackaday-retro-edition-a-new-commodore-64-case/
I never had the pleasure of owning a C64, but I always wanted to play around with one, especially with some of the MIDI sequencer software floating around. I couldn't help myself, and decided to back the Kickstarter and get one of the enclosures. After hearing a horror story about a factory fire from the Kickstarter update, I started to doubt that the enclosure would ever show up... Until today today, when I received a mysterious package containing...
I am still working on sourcing a board, but I have a line on several non-functional ones. I'm hoping that with a couple bad boards, the original schematics, and some soldering iron time, that I can cobble together a working C64. Having the enclosures sitting here certainly makes the project feel more likely to actually happen. Stay tuned for more updates!
Wednesday, February 4, 2015
Z80 Computer - Bus Buffering Rev 1
The original draft (and parts order) of my Z80 machine had a buffering scheme largely borrowed from the ZAP machine, described in Build Your Own Z80 Computer by Steve Ciarcia. It consisted of three 74367 6-Bit Non-Inverting Drivers, and two Intel 8212 8-Bit Input/Output Ports*.
The 74367 chips acted as the address bus buffer, leaving 1/3 of one of the chips unused. The 8212 ports were wired back to back, using BUSAK to disable the address bus drivers, and RD to switch between the Input configured 8212 and the output configured 8212.
Once I got to building the circuit on the breadboard in anticipation of my initial LED test, I started to realize that my chip count was going to be very high, and there was a LOT of wiring involved in the buffering alone.
I took a step back from the project for a bit, and browsed around Digikey and Jameco, read a few datasheets, and I'm thinking that using a pair of 74LS541 Octal Tri-State Line Drivers for the address bus and a 74LS245 Octal Tri-State Transceiver for the data bus might be the way to go. It certainly simplifies the wiring and lowers the chip count.
* The 74412 appears to be pin compatible with the 8212. I have not evaluated the datasheets of both parts to know whether the 74412 can be a direct replacement or not, but I did use it rather than create a new library footprint in Eagle. Check the datasheet before using the 74412.
The 74367 chips acted as the address bus buffer, leaving 1/3 of one of the chips unused. The 8212 ports were wired back to back, using BUSAK to disable the address bus drivers, and RD to switch between the Input configured 8212 and the output configured 8212.
* The 74412 appears to be pin compatible with the 8212. I have not evaluated the datasheets of both parts to know whether the 74412 can be a direct replacement or not, but I did use it rather than create a new library footprint in Eagle. Check the datasheet before using the 74412.
Wednesday, January 28, 2015
Z80 Computer
Work has begun on a project that I have wanted to do for many years, and put off for one reason or another. A few months ago, I decided that I wanted to (finally) build a Z80 machine from scratch, get it to run CP/M, and play a game of Zork. I hadn't the foggiest idea what it would take, but I have picked up a touch of electronic and programming background over the years, so I decided to take a hack at it.
After a few months of research, design, and waiting for shipping, the first breadboards are starting to go together. The machine will be a Z80A CPU running at 4MHz with 64k of RAM and 32k of ROM. I intend to use a Zilog Z80-SIO with a MAX232 to communicate with an old NEC dumb terminal that I have laying around for control.
So far I have constructed the clock, the reset circuit, a single-instruction step circuit, and the beginnings of the bus buffering and signal/address decoding. I intend to detail each circuit in an individual post including relevant schematics and measurements.
My first test will come shortly, once I finish wiring up the buffers. I will be pulling the entire data bus low, and hooking LEDs to the buffered address bus output. If all goes well, the CPU will read NOP off of the grounded data bus, and proceed to increment the address bus every time I run the single-instruction stepper. The end effect -- A 16 bit binary counter.
From there, I can go into decoding, RAM/ROM, peripherals, some kind of storage, writing a ROM monitor, writing a custom CP/M BIOS, and on, and on, and on. Oh well, I needed a project and more material for this blog anyway, and from the looks of it, I've got plenty to do now.
After a few months of research, design, and waiting for shipping, the first breadboards are starting to go together. The machine will be a Z80A CPU running at 4MHz with 64k of RAM and 32k of ROM. I intend to use a Zilog Z80-SIO with a MAX232 to communicate with an old NEC dumb terminal that I have laying around for control.
So far I have constructed the clock, the reset circuit, a single-instruction step circuit, and the beginnings of the bus buffering and signal/address decoding. I intend to detail each circuit in an individual post including relevant schematics and measurements.
My first test will come shortly, once I finish wiring up the buffers. I will be pulling the entire data bus low, and hooking LEDs to the buffered address bus output. If all goes well, the CPU will read NOP off of the grounded data bus, and proceed to increment the address bus every time I run the single-instruction stepper. The end effect -- A 16 bit binary counter.
From there, I can go into decoding, RAM/ROM, peripherals, some kind of storage, writing a ROM monitor, writing a custom CP/M BIOS, and on, and on, and on. Oh well, I needed a project and more material for this blog anyway, and from the looks of it, I've got plenty to do now.
Wednesday, October 1, 2014
Patching Debian 5 for ShellShock
Debian 5 is, sadly, no longer supported by the friendly folks over at Debian. Like the rest of the internet, it's default version of bash is quite vulnerable to the ShellShock vulnerability.
To clean up the mess we have going here, start off by ensuring that the system is up to date (Debian 5.0.10 is the latest in the repositories. If you haven't already switched over to the archive sites for the upstream repositories in order to get package updates, update your /etc/apt/sources.list to point at the Debian archives (see the FAQ section at https://wiki.debian.org/DebianLenny). Then run an 'sudo apt-get update && sudo apt-get upgrade'.
Post-upgrade, /etc/debian_version should show the system at 5.0.10. In order to update bash, grab the bash-3.2 sources here: https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz
Unpack them, and run a bit of bash to patch the sources up to 3.2.55:
#!/bin/bash
wget https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz
tar -zxvf bash-3.2.tar.gz
cd bash-3.2
for x in `seq 1 55`
do
curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-`printf "%03d" $x` | patch -p0;
done
./configure
make
make tests
Then do the standard GNU install with "sudo make install".
To clean up the mess we have going here, start off by ensuring that the system is up to date (Debian 5.0.10 is the latest in the repositories. If you haven't already switched over to the archive sites for the upstream repositories in order to get package updates, update your /etc/apt/sources.list to point at the Debian archives (see the FAQ section at https://wiki.debian.org/DebianLenny). Then run an 'sudo apt-get update && sudo apt-get upgrade'.
Post-upgrade, /etc/debian_version should show the system at 5.0.10. In order to update bash, grab the bash-3.2 sources here: https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz
Unpack them, and run a bit of bash to patch the sources up to 3.2.55:
#!/bin/bash
wget https://ftp.gnu.org/pub/gnu/bash/bash-3.2.tar.gz
tar -zxvf bash-3.2.tar.gz
cd bash-3.2
for x in `seq 1 55`
do
curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-`printf "%03d" $x` | patch -p0;
done
./configure
make
make tests
Then do the standard GNU install with "sudo make install".
Wednesday, August 14, 2013
Observium On OpenBSD
Note: The following is a blow by blow of the installation, told in story form. If you intend to follow this as a guide to the installation of Observium in OpenBSD, please read through to the end before starting the installation. I will be show config snippets at varying stages of broken-ness.
Always being one to enjoy a technological challenge, I was presented with the task of building out a new management network. I firmly believe that management of all devices on a network needs to be out of band from the rest of the network operation, so I was quite happy to take on this task. After installing the new switches, and getting all of the monitor ports cabled up, I stopped to contemplate how I would set up my network monitoring suite, and how I would access this OOB network remotely.
Being a project that requires security (someone finding their way onto this network could be catastrophic), I decided that the best course of action was to set up a machine with a NIC in both my internal and my management networks, and run OpenBSD 5.3 on it. A few months ago, the friendly folks over at #juniper on freenode recommended Observium as a network monitoring suite, and I have found it to be a fantastic project so far. The Observium installation documentation is very clear that it supports Ubuntu/Debian only. There is a second set of installation instructions for RHEL/CentOS.
So off I went with my OpenBSD installation, knowing full well that the Observium installation was probably going to be a painful one, but the machine that spans the gap between the two networks is a prime location for my monitoring utilities, so I decided to do it anyway. Starting off with the OS installation, I accepted the defaults for the most part, configured my NICs for my network, and allowed OBSD to work its own disklabel magic (use the whole disk, autopartition). When it came time to choose installation sets, I simply issued a -x* -games*, and went along my merry way (not fully appreciating the implications of my actions at the time). Once the install was done, and I was presented with a prompt, the first order of business was to get the package mirror set up so I could begin installing the prerequisite software for Observium. I chose to use the mirror in Denver, CO, USA. This involved adding one line, and changing one line in .profile (changes in bold):
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
PKG_PATH=ftp://ftp3.usa.openbsd.org/pub/OpenBSD/5.3/packages/amd64/
export PATH PKG_PATH
Next, we need to get a proper editor, and a few tools:
# pkg_add -vi vim nmap svn
After everything is done installing, I picked up the prereqs for Observium from their install documentation:
# pkg_add -vi fping mysql-server net-snmp rrdtool graphviz php
This will chug along for a while, and occasionally ask a question. When prompted for a php version, I chose the latest 5.3 release (per the prereqs), in the non ap2 build (this is for Apache 2, but Apache 1.3 ships with OBSD out of the box). But... the damn thing breaks on rrdtool... After a bit of Googling, I discovered that the required libraries are part of xcore53... one of the packages that I opted to not install earlier. SOOOOO, off to the closest mirror to grab xcore53.tgz, and run a cd / && tar -zxvpf ~/xcore53.tgz, start the pkg_add over, and we're done.
I brought up the mysql database with /usr/local/bin/mysql_install_db, then set the root password, and created a database for Observium according to the installation instructions. I set the database credentials in /var/www/observium/config.php.
Next, I decided to install observium into /usr/local/observium, as I didn't like the idea of using /opt. I pulled the code down via SVN per the instructions on the site, and dropped the config snippet from the RHEL instructions into /var/www/conf/httpd.conf, with some minor modifications:
ServerAdmin webmaster@localhost
DocumentRoot /usr/local/observium/html
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
ErrorLog /usr/local/observium/logs/error.log
LogLevel warn
CustomLog /usr/local/observium/logs/access.log combined
I wound up chasing my tail for an hour or two messing with the httpd configs, before I realized that httpd had chrooted itself into /var/www (hence the funny config location). I quickly moved the Observium install over to /var/www/observium, and changed the httpd config again:
ServerAdmin webmaster@localhost
DocumentRoot /var/www/observium/html
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
ErrorLog /var/www/observium/logs/error.log
LogLevel warn
CustomLog /var/www/observium/logs/access.log combined
Much better! Now we get an error about the database. pkg_add -vi php-mysql
Now getting an error about not being able to bind to the MySQL socket. Wow, wonderful. More Googling revealed that, yet again, the chroot was biting me:
# mkdir -p /var/www/var/run/mysql
# ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
Now that we're past that, OH LOOK, It's a 500 error! After a few hours of sticking die()'s into the code, I figured out that since I was in a chroot, the install_dir variable would be relative to /var/www. Once this variable was set from /var/www/observium to /observium, the web UI loaded right up. When I attempted to add a user, I found that adduser.php was now throwing errors about not being able to find functions that should have been included with common.php. Turns out that even though Apache is chrooted, the php cli, is not. DOH! ln -s /var/www/observium /observium It's a hack, but hey, it works now... Kind of... In reality, it just fails differently. Turns out I missed a step in the install documentation, and didn't initialize the database...
After I got the DB initialized, and a user created, I realized that addhost.php wasn't working. After more tinkering, I realized that all of the default paths for the utilities were wrong, because the software was designed to run in Linux. I grabbed the whole block of utility path define()'s out of the defaults file, and gave them the correct paths, and lo and behold! OBSERVIUM IN OBSD.
I will most likely be revisiting this topic in the not-too-distant future, as I find more things that I need to hack around, but for the time being, It looks like I have monitoring running on the machine I wanted it on. Now it's time for pf!
Always being one to enjoy a technological challenge, I was presented with the task of building out a new management network. I firmly believe that management of all devices on a network needs to be out of band from the rest of the network operation, so I was quite happy to take on this task. After installing the new switches, and getting all of the monitor ports cabled up, I stopped to contemplate how I would set up my network monitoring suite, and how I would access this OOB network remotely.
Being a project that requires security (someone finding their way onto this network could be catastrophic), I decided that the best course of action was to set up a machine with a NIC in both my internal and my management networks, and run OpenBSD 5.3 on it. A few months ago, the friendly folks over at #juniper on freenode recommended Observium as a network monitoring suite, and I have found it to be a fantastic project so far. The Observium installation documentation is very clear that it supports Ubuntu/Debian only. There is a second set of installation instructions for RHEL/CentOS.
So off I went with my OpenBSD installation, knowing full well that the Observium installation was probably going to be a painful one, but the machine that spans the gap between the two networks is a prime location for my monitoring utilities, so I decided to do it anyway. Starting off with the OS installation, I accepted the defaults for the most part, configured my NICs for my network, and allowed OBSD to work its own disklabel magic (use the whole disk, autopartition). When it came time to choose installation sets, I simply issued a -x* -games*, and went along my merry way (not fully appreciating the implications of my actions at the time). Once the install was done, and I was presented with a prompt, the first order of business was to get the package mirror set up so I could begin installing the prerequisite software for Observium. I chose to use the mirror in Denver, CO, USA. This involved adding one line, and changing one line in .profile (changes in bold):
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
PKG_PATH=ftp://ftp3.usa.openbsd.org/pub/OpenBSD/5.3/packages/amd64/
export PATH PKG_PATH
Next, we need to get a proper editor, and a few tools:
# pkg_add -vi vim nmap svn
After everything is done installing, I picked up the prereqs for Observium from their install documentation:
# pkg_add -vi fping mysql-server net-snmp rrdtool graphviz php
This will chug along for a while, and occasionally ask a question. When prompted for a php version, I chose the latest 5.3 release (per the prereqs), in the non ap2 build (this is for Apache 2, but Apache 1.3 ships with OBSD out of the box). But... the damn thing breaks on rrdtool... After a bit of Googling, I discovered that the required libraries are part of xcore53... one of the packages that I opted to not install earlier. SOOOOO, off to the closest mirror to grab xcore53.tgz, and run a cd / && tar -zxvpf ~/xcore53.tgz, start the pkg_add over, and we're done.
I brought up the mysql database with /usr/local/bin/mysql_install_db, then set the root password, and created a database for Observium according to the installation instructions. I set the database credentials in /var/www/observium/config.php.
Next, I decided to install observium into /usr/local/observium, as I didn't like the idea of using /opt. I pulled the code down via SVN per the instructions on the site, and dropped the config snippet from the RHEL instructions into /var/www/conf/httpd.conf, with some minor modifications:
ServerAdmin webmaster@localhost
DocumentRoot /usr/local/observium/html
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
ErrorLog /usr/local/observium/logs/error.log
LogLevel warn
CustomLog /usr/local/observium/logs/access.log combined
I wound up chasing my tail for an hour or two messing with the httpd configs, before I realized that httpd had chrooted itself into /var/www (hence the funny config location). I quickly moved the Observium install over to /var/www/observium, and changed the httpd config again:
ServerAdmin webmaster@localhost
DocumentRoot /var/www/observium/html
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
ErrorLog /var/www/observium/logs/error.log
LogLevel warn
CustomLog /var/www/observium/logs/access.log combined
Much better! Now we get an error about the database. pkg_add -vi php-mysql
Now getting an error about not being able to bind to the MySQL socket. Wow, wonderful. More Googling revealed that, yet again, the chroot was biting me:
# mkdir -p /var/www/var/run/mysql
# ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
Now that we're past that, OH LOOK, It's a 500 error! After a few hours of sticking die()'s into the code, I figured out that since I was in a chroot, the install_dir variable would be relative to /var/www. Once this variable was set from /var/www/observium to /observium, the web UI loaded right up. When I attempted to add a user, I found that adduser.php was now throwing errors about not being able to find functions that should have been included with common.php. Turns out that even though Apache is chrooted, the php cli, is not. DOH! ln -s /var/www/observium /observium It's a hack, but hey, it works now... Kind of... In reality, it just fails differently. Turns out I missed a step in the install documentation, and didn't initialize the database...
After I got the DB initialized, and a user created, I realized that addhost.php wasn't working. After more tinkering, I realized that all of the default paths for the utilities were wrong, because the software was designed to run in Linux. I grabbed the whole block of utility path define()'s out of the defaults file, and gave them the correct paths, and lo and behold! OBSERVIUM IN OBSD.
I will most likely be revisiting this topic in the not-too-distant future, as I find more things that I need to hack around, but for the time being, It looks like I have monitoring running on the machine I wanted it on. Now it's time for pf!
Subscribe to:
Posts (Atom)