Last updated: 18 Oct 2009 - 21:08
More progress on the Z80 project; I have fitted the first RAM chips tonight. After sorting the code so far into 3 source files, I implemented the memory read and memory write functions. These appeared to work on single memory locations, so I implemented the block read and write functions. Using a Python script (see the Z80 Project page for the file) I wrote the XOR combination of the high and low address bytes to each memory location, then read the memory back and tested it against this value.
So far I've fitted one 32K RAM chip in the lower half of the address space and an 8K chip in the upper half. This shows up correctly on the memory check. The script writes address from the top down, so when the 8K chip gets written with the data for the top 8K of memory this is subsequently over written with the chip in its lowest possible space. Hence the memory scan determines that there is memory up to address 0x9FFF (40K).
Due to the maximum packet size of 256 bytes, the maximum d
Last updated: 14 Oct 2009 - 22:36
I've re-arranged the site a bit. I've added a new section with its own link at the top of the site entitled "Z80 Project". This page gives quick access to all the information on the project and links to downloads. At the moment I've not put much on the page, but I'll add stuff as I get it sorted enough to publish.
I've also been coding. I've got the first commands running, I can change the LED status on the debug port with a command sent over the serial link now. A lot of the background code to do with bus management etc. is all sorted out as well now (although not very thoroughly tested). The biggest change to take note of since my last bit of documentation on the website though is that I've scrapped the ASCII based command codes. This initially seemed like a good idea because the commands could be sent from any text-terminal, but since the packet format evolved to require a binary packet length field, this advantage was lost. So I dumped the ASCII to reduce the over head a
Last updated: 09 Oct 2009 - 20:54
More progress has happened already!! I managed to get a basic comms protocol up and running to allow a flexible command structure for accessing the PIC's debug functions. The comms protocol makes considerable use of the 18F's additional commands and indirect addressing, and is quite generous with RAM since the 4520 version has 1.5KB available.
Last updated: 06 Oct 2009 - 15:18
So, I got some lights flashing over two weeks ago and then went quiet, "what's been going on?" you may well ask. Once I got the lights flashing, I wrote another demo that does a chase across the row of LEDs, this would show up if any of the tracks on the data bus were shorted as each led is lit individually and is driven by a single bus line. Once I'd done that I started work on the serial port code for the PIC's onboard serial port. The basic send and interrupt on receive code is working so it echoes each character it receives back at the moment. However to test the code in the PIC I needed a nice serial-terminal application so decided to write one with PyGTK, threading and python-serial. I've got that working fairly well now, once I've developed it a bit more I will probably release it somewhere.
However, I hit something of a problem while studying data sheets. It explains why no one has tried this whole running DMA while the Z80 is in reset idea before. Basically while the
Last updated: 20 Sep 2009 - 17:38
I have made some progress on the Z80 project. Another mod, some software and learned some new lessons about PIC programming on Linux.
Another Mod I realised the other day that my plan to start testing peripherals with the PIC before inserting the Z80 would not work. My design has bus buffering to ensure the mash up of TTL and CMOS components all get valid signals. However the decision about what chip is driving the bus is made based on the status of the BUSACK line from the Z80. This means that without the Z80 fitted, or with it held in RESET the two sets of bus drivers (one from the Z80 and one from the PIC) could be in conflict as their enable line states are undefined. To deal with this problem I've added a 10K pull down resistor under the Z80, this will make sure that if the Z80 isn't driving the pin (because it's not fitted or it's in reset) the PIC has control of the data bus.
Software The first bit of software I wrote was a trivial
Last updated: 09 Sep 2009 - 13:33
I had a day or two waiting for parts to arrive recently, and started tinkering with PIC programming in Linux. I was really pleased with how easy it was to program a PIC with my PICKit 2 programmer using the available command line tools, but what I wanted was an even easier GUI interface for it. So I wrote one.
It's not very polished and has had only minimal testing so far, but it should be useful. Basically I wrote a PyGTK user interface that executes the most popular command line operations such as compile a source file, program the PIC or power the PIC and release MCLR to test the application. The full details of the software (licensed under GPL V3) are on my open-source electronics site: tuxtronics.com.
Last updated: 09 Sep 2009 - 12:34
Too lazy to type out the commands every time I wanted to do something to my project and with a couple of days spare before parts arrived, I decided that what I really needed was a little GUI to run the commands for me. I've used gpasm as my assembler (from GNU PIC Utilities) and the PK2CMD program hosted on the Microchip Website as the back end for this application.
Essentially this is a very simple Python powered GTK interface that executes a number of the most common command line instructions used in PIC development when you click one of the buttons. It provides some feedback to the user about how the command went.
Checkout the documentation at the end of this page, and try out the application [see https://github.com/hairymnstr/dwarf for the latest version].
Last updated: 02 Sep 2009 - 22:26
I've made some progress on the Mark 2 project and started the Mark 3!! First the Mark 2, I've built the system that I detailed in the articles on the Mark 2. There are a few odd bugs that I spotted as I tidied the circuit diagrams to add to the articles, these will need minor re-wiring of a bit of the glue logic. I kept the system on two bits of strip-board with the CPU and the PIC on the top layer with a bit of glue logic, the rest of the system (I/O decode, memory and peripherals are all on a lower layer, interfaced with 4 ten-way pin headers and receptacles. (Pics will follow soon). The pin-outs of the connectors can be seen in the circuit diagrams.
I've done electrical testing on the system so far. All of the power pins have the right voltages on them, including the +/-10V outputs on the MAX232 chip. The clock output on the 74HC4060 chip that provides the clock for the UART is stable and at the correct frequency. The PIC also registers with the correct part number when c
Last updated: 26 Aug 2009 - 23:06
The CPU in this system is a Z80 of course. There isn't much to this section in way of technical content, just a few explanations of what pins I've ignored and why really. I'm not using the RFSH pin as I'm using static RAM, I can't think of a reason to use this in a modern system, and can think of lots of reasons not to, DRAM is just too much like hard work if you ask me. I've not connected anything to halt as I didn't really have room on the board in the end, it is often handy to put an LED on here (although it should be driven with a transistor as this pin can't sink/source much current). I've not used the non-mask-able interrupt so that's tied high to stop it going off by accident, the M1 line is not used in this simple system, so is left un-connected.
There are two interrupt sources in the system, the clock and the UART, so the interrupt signals are combined with a simple AND gate, (remember if you want a trigger on either one OR another active low signal you must AND them, l