The parts arrived and it was time to fit them and begin to test the power supply.
One piece of test equipment that I had been missing for a while was a bench isolation transformer. This would have allowed me to perform tests and repairs that would protect me and the equipment being tested.
After looking around, I found it very difficult to find a device that met my requirements. Everything I found was too expensive or did not have what I wanted – a device with both voltage and current meters, with fuses on both the primary and secondary and an auto current trip on the input.
In the end I decided to build my own unit.
The core of the system was two identical transformers, wired back to back, to provide the isolation. These were sourced from some faulty UPSs, sourced on eBay. They were missing their batteries, but were working. I scrapped the UPSs and removed the parts that were worth keeping.
I recovered the current trip switch from an old Intermec 3400 Barcode Printer with a damaged chassis.
I was able to get a combination voltage/current/power meter on eBay, with a 6 week delivery from China.
The last few parts were a case and some IEC power connectors for both the input and the output, as well as fuses and fuse holders that I had in stock for many years.
The secondaries of the transformers were wired back to back – this provided dual isolation via the windings on both transformers. So when I tested it and connected the mains to the primary of the first transformer, I measured 230v AC on the primary of the second transformer. This proved that my theory worked, yay!
The meter gave me an indication when the device under test drew too much current, as well as showing the power draw. You may be thinking why did it show the current and voltage when the device was connected to the mains?
Well, I planned to connect the primary side of the isolation transformer into the output stage of a variac. A variac is a transformer with a variable output.
This allowed me to slowly increase the voltage to the device under test. I could see if the current draw was excessive and identify faulty equipment without having to connect the device to the mains and possibly blowing components, causing even more damage.
Note:Variacs are very handy devices that can be used to recondition old power supplies that may not have been used for a long period of time.
These two units coupled together provided me with a good environment to test devices for repair, while protecting myself and the customers device being repaired.
A female IEC connecter is used for the power output. This allowed me to have a selection of different leads that could plug in here.
Here is a photo of the Isolation Transformer connected to a Frequency Inverter. You can see that the meter is showing the output voltage, current that was being drawn as well as the power consumed.
The back of the unit just has a power input connection and an input fuse for protection.
Having decided that I was going to use an Atmel ATF22LV10C PLD to manage the address decoding for this project, I purchased a couple of these IC’s to try out. I was visited by Murphy’s Law. I found out that the new programmer wouldn’t program these ICs (although it listed these as supported ICs). After searching some forums, I found that I wasn’t the only person having a problem programming these ICs on this model of programmer. It turned out that the problem was down to the flash memory in the Atmel PLD. It required some special timing to program the ICs, which this programmer did not support.
So, my second attempt into this problem was to purchase some National GAL22V10 ICs (which my programmer said it also supported), but did I believe them? After testing them on my programmer and finding that they also didn’t work, I was getting very frustrated (serves me right for buying a cheap Chinese one). I really didn’t want to purchase a new programmer at that point, considering that it did work for other ICs.
Just to prove to myself that I was not losing it and that my grey matter was not shutting down, I tried some Lattice and National GAL16V8 ICs that I had in stock, and these programmed with no issue. I needed to rethink the address decoding, as I could use the working parts that I had to hand.
I was not happy to add two additional ICs into the project where I wanted to use one. Could I remove another IC to keep the chip count the same as before? After looking at the schematic it was simple to see that the /RE & /WE signal lines could be incorporated into one of the GALs.
If the first GAL contained the logic for these decoder lines (/RE & /WE) as well as the address decoding for the memory map, the second GAL could be used for the address decoding of the I/O.
This all seemed like a good plan, but NO, there was one sneaky problem that had now crept back in. The current consumption then increased dramatically in the system. Before we even measured this, I estimated that these GALs would burn about 40-80mA each (80 – 160mA in total). This blew the power budget that I wanted as a limit for the system.
As low power consumption was a key prerequisite for this project and as I then could not use the PLDs, I had to look back to using basic logic devices for managing the address decoding. It looked as if we would have to use some 74HC138s and 74HC139s. In the end the chip count increased.
That was a month’s work and planning that I wasn’t getting back.
All the memory devices require an active low control line and A15 will be high when the CPU is reset/starts. We can just use an inverter to get an active low signal from the A15 line which is high when the CPU starts. This is done by feeding A15 into a NAND gate 74HC00 (U4A), in an inverter configuration.
This active low A15 signal with A14 and A13, feed into a two to four line decoder 74HC139 (U5A), which allows us to cut the upper 32K memory space into 4 x 8K pages. Three of these pages can be used for our ROM memory which stores our software. The last 8K page can be used for future expansion, video memory and I/O.
This I/O control line can be fead into another NAND gate 74HC00 (U4B), with address line A9. This gives us a memory space of 512 bytes – it make better use of the memory space. We can feed this control line with A8 and A7 through A5, into a three to eight line decoder – 74HC138 (U10). This gives us 8 x 32 byte address blocks, which can be used for I/O devices such as RTC, UARTS, PIAs.
As we can see there are some unused memory spaces in the revised memory map. These can be used by other interfaces in the future.
So, after a couple of weeks since writing the first post about this Micro, I’m rethinking the address decoding and mapping of the same. Currently, address line A15 is being used to select between the lower 32K of memory and the upper 32K of memory. In the lower 32K of memory, I will page 32K block of RAM in and out, as needed. While the upper 32K of memory will be used for ROM and video RAM. I had previously suggested using a 3-8 line decoder to break up the upper 32K of memory into 4K chunks and then join a few of them to give 8K chunks. After a few days of writing the post about address decoding, I realised there were a few options available.
If I use a 2 to 4 line decoder (74HC139), I can use address lines A14 and A13 to break the upper 32K of memory into 4 x 8K blocks (which makes it easier for memory management). The upper 3 x 8K blocks can be used for firmware. I can potentially look at paging out one or two of these 8K blocks.
The lower 8K page can be sub divided into 4 x 2K blocks using another 2 to 4 line decoder (74HC139) on address lines A12 and A11. One of these 2K blocks can be used for basic video memory. If I add a second or third 2K block this would give 4K or 6K of video memory, which would suffice for a basic 40 column x 25 line or 80 column by 25 line display (with some basic colours and cursor functions).
The lower 2K block can be sub divided into 8 x 256 byte pages for I/O. This is still allot of wasted address space for I/O, so what can be done to be more efficient with the memory usage?
We can use a programmable logic device , a “PLD”, to manage the control logic for the I/O. This way we can re-program the PLD at a future date to incorporate any additional changes to the I/O that we may want.
Using an Atmel ATF22LV10C will give us up to 10 outputs each, which can be individually assigned to one or more addresses. With up to 12 address inputs, the PLD makes it easier to map the control lines required. The unused pins on this device will be brought out to a header in case we need to use these pins at a later date. This is a simpler solution to the multiple address decoders and additional logic ICs that potentially we were looking at.
When looking at the above revised memory map, we can see the I/O region is spread over 256 bytes of memory.
Years ago I used us a Hi-Lo Programmer that connected to my PC via an ISA card. This device was supplied with its own DOS program for taking Boolean logic and producing a map file which could be programmed into a PLD or a GAL. As I can’t use this anymore on modern PCs or a laptop, I need to find a more modern solution.
So I purchased a G540 programmer on eBay for very little money. The G540 was supplied with some adaptors for PLCC devices. A chip extractor was also supplied with this package. This programmer has a USB port, so it can connect to my laptop or desktop PC.
Atmel has a utility call WinCupl which allows you to write Boolean logic and create a map file which can be programmed into the 22LC10 PLD. I’ve never used this program before, so a little bit of study will be needed.
While working on the Retro Computer Project, I was looking to build a small interface that would let me connect to the address and data bus of the Micro to provide a method to manually program the micro as well as read/write data into memory.
Back in the last century there was a logic IC that provided this function, but I couldn’t find it anywhere. There were plenty of the BCD to 7 segment decoders, but nothing that would give values above 9 such as A, B, C, D, E & F.
Time for a quick project and to quickly put something together! So I looked at what I had available and had a boot load of PIC 16F628 Micro controllers. So if you can’t find what you are looking for, build it!
As my goal was to get something to put together in a couple of hours that I could use quickly, I was not thinking about how efficent the code would be, so there may be better ways of doing this. Please feel free to take the code and schematic for this Binary to Hex 7 Segment decoder and use it for your own projects. All I ask is that you link or reference back to me and this project.
With this project, the first step was to define my requirements, my outputs and inputs. Obviously I needed to drive a 7 Segment LED display (common cathode). I needed an input to latch data into the decoder and wanted to have a test function as well as a blanking input.
I used the internal oscillator on the PIC as the clock, set to 4MHz. The main loop in the code checked to see if any of the control lines were active. If any of these control lines were active (low) the PIC microcontroller would perform the necessary action. The data for the decoder was latched into the buffer prior to decoding.
You can ignore the switches to the left of the PIC in the schematic, as there were just used to simulate the control lines and the data input. The resistors to the right of the PIC were just current limiting resistors for each of the 7 segments in the LED display.
The code was fairly simple and can be broken down it to a few sections. The first being the port setup code. As the PIC has many multi-function pins, its very important to set these correctly at the start. One mistake that I made was to forget to turn off the analogue comparators on PORT A, ended up wasting an hour looking at this, until the penny dropped.
In the main loop of the program, I started by reading the data on PORT_A and then performed a test to see if any of the control lines had gone active low.
You will notice in the code, that the first test performed is for the Blanking Input – if this was not active then the code would check for the Test Display Input. As this was nested inside the if-else statement for the Blanking Input, the Blanking Input had priority over the Test Display. This was one simple way to implement such logic.
When the control lines were active, I wanted to ignore any update from the Latch line, so a simple flag was used to achieve this.
The code for then managing the control lines was very simple. It could well have been included in the main. I have found by experience, it is always better to have separate function code block for every action. This makes the main code loop easier to read and when you’re troubleshooting, you’re not finding yourself going back over blocks of code again.
In this screen shot you can see the first few lines of the code for the section that converted the binary data into values for the 7 Segment display. In the first line of code I was performing a logical AND to clear out the upper bits of the data, as these bits were the control lines on PORT_A.
Next I compared the data with values from 0 to F inclusive. Based on the value I switched on the different segments of the LED display. I left the formatting of this in binary as I thought this might make it easier for other to read.
You will notice in the code segment above, there is a line that is commented out. This was my debug function, which was used to flash the LED decimal point x number of times, to indicate the value of the data input. This is a good point to bring up. When building any system large or small, it’s always handy to have some form of debugging build in. Just having a simple LED to flash, can save a engineers time, as there is nothing better than a visual indicator to let the person know that they have reached that point in the code.
The source code for the project which was developed in MPLABX is included below. Please feel free to copy and modify the code as you need for your project. I’m just going to program 6 of these for the Retro Computer Project and build the interface board next.