Saturday, 31 August 2013

Acorn Archimedes A3000 Repair

A recent video by Dave Jones on his EEVBlog showed a tear down of an Acorn A3000 (I think they had officially dropped the Archimedes name at this point, but it is still sometimes referred to as an Archimedes 3000 or Archimedes A3000). The one Dave had suffered from what is sadly a common fault on this range of machines (and things like the Commodore Amiga A501), that of battery leaking and damaging the boards. Knowing this often wrote off the boards, I had been looking for a cheap A3000 that looked good externally, but where the main board was shot. My plan was to 'upgrade' the ARM2 processor to the ARM11 of a Raspberry Pi. I was going to convert the keyboard (like my other Vintage USB keyboards) and run RISC OS on it, so externally, it would look like an A3000, just inside would be the pi rather than the A3000.
Looks ok, doesn't it? Many of these had school names etched into the top of them. This is also the A3000 which is the last model to have BBC style red function keys. The later A3010 and A3020 had green function keys and no reference to the BBC heritage.
Again, the inside loosk OK. The expansion cover is missing, there is no econet module or serial upgrade. There is however a 3MB upgrade (taking the memory to 4MB in total). The horrors lurk under the keyboard - those of a nervous disposition look away now...
Over the 20-25 years since these machines were manufactured, the batteries have leaked an alkali solution over the area of the board around them. In the case of the A3000, that is the RTC / CMOS RAM and the 4 ROM chips (RISO OS runs from RAM, so no need for an OS disk like the Amiga).
The alkali can eat away at the copper, and indeed both the legs of the 32.768KHz crystal had gone, as had one leg of a capacitor. The tracks all seemed intact, bar one connection from the RTC chip to the crystal which I patched up.
As horrid as it looks, a wash in a vinegar solution and a clean with IPA seems to have brought it up nicely. Originally, the battery was a 1.2V rechargeable, and the user guide recommended having the machine switched on at least 1 hour a week to keep it topped up. I didn't fancy that, so I went for a standard CR2032 3V battery, as used on almost all PC motherboards these days. The PCF8583P RTC chip claims to work from 1.0 to 6.0V, so 3V should do nicely. I added a diode in series to stop it trying to change the battery and powered it on.
I didn't get any photos of the screen at this point, but it wasn't a great start, the settings were wrong (it defaults to all the ROMs being virtually 'unplugged', like the BBC Master), so was just showing 'Supervisor'. However, I couldn't get a stable picture. I didn't want to reset the config until I could see what was going on. The LCD TV wouldn't lock on to the sync, so I tried the composite video on a Commodore 1901 monitor. Same thing. The 1901 has an RGB input, so I made up a lead for that and tried. Same again.Testing it with the scope showed the sync was around 31Khz, not the 15.4KHz I'd expect - it seems the machine was in high res mode. So I went for the factory reset (hold down delete whilst powering it up). I got the screen with a red border which synced up fine, and then up came the loading screen.
It looks to have been upgraded to RISC OS 3.11, which is the last version supported on this hardware. And there we have the RISC desktop.
There is still the issue of a mouse. I didn't get one with this machine, and they are tricky to find (round 9 pin connector, discrete wired buttons and quadrature outputs).
For the moment, pressing F12 allows you to type. All the keys and the floppy disk seem to work fine. Acorn always seem to be on the ball when it comes to thinking about expansion, and I found places on the board where sockets could be fitted for alternate mouse and keyboard connections. They are both controlled by an 8051 based microcontroller which converts key presses and mouse moves to serial data, presumably using the same protocol as the controller in the external keyboards on the earlier A400 series machines. There is even a jumper to interrupt that serial data and inject new traffic. So in theory, if I can work out the protocol, I could add a microcontroller with a mouse and convert it's output to serial and inject it into the system as if it had come form the 8051.
Having fixed it, that put paid to my plan to install the Raspberry Pi, I think I need to look for one a bit more broken - or try less hard to fix the next one.

Monday, 26 August 2013

ZX81 Clone Part 2 - ZX80 Clone

Following on from the previous article where I built a ZX81 on breadboard using the original chips and then modern equivalents of all but the irreplaceable ULA, I moved onto the next step, which was to replace the ULA. There are many alternative circuits on the next (I've already admitted I'm reinventing a wheel that's already been reinvented), however, the simplest circuit and a good starting point is actually the ZX80, so I started with that. There are rather a lot of chips required, so first I'm going to need a bigger breadboard. The one I had been using for many years seemed quite good, so I got another one of those to double the area. However, I took the opportunity took make a small improvement. The previous builds have taken power from the posts via wires to the top rails, and then via wires down the sides, and via smaller jumpers, across the top. Having all the rails separate does give increased flexibility, but pretty much everything I had built on there had been using the same 5V rails all wired together.
This had worked fine, but was a little untidy and limited the usable space a bit. So before I started, I took the new one apart to see if I could wire up all the rails up behind the board. Firstly the left and right sides of each rail were wired together.
Next each rail was soldered to a wire at one end.
These were there threaded through holes, glued in place and bolted to the posts.
This gave me a clean board with power to all 6 rails.
So no more delaying tactics, time to build a ZX80 clone. I followed the ZX80 circuit more or less. I made a couple of changes for layout and practicality, I kept with the 16K RAM and 74LS04 for the crystal oscillator that I'd used on the ZX81 and used a single 74LS245 instead of a pair of 74LS05's for the NOP generator (I ran out of space!).
I also jumped the gun on the next modification and added a couple of gates to generate the back porch and make the video signal suitable for a modern TV (the 'white level restoration' section from Grant Searle's ZX80 page).
So here is the ZX80 clone, next to the original I was using to compare signals. The top of the left hand board has the Z80, RAM and EPROM, below that, the things which use the address and data buses: the NOP generator, the input port at 0xFE, the character latch, address generation and video shift register. The top right is the rest of the glue logic, and the bottom right is the additional video tidying up and output buffer.
Next, I added the remainder of the NMI generation circuit as per Grant's page, which should in theory make it fully compatible with a ZX81. That has filled up the right hand side of the breadboard as well and it is looking rather messy now.
Unfortunately, somewhere there is at least one of these wires in the wrong hole - it may take some time to find out which.

To be continued......

UPDATE - I did just about get this working, but the breadboard version had some intermittent connections, so I didn't get much further with that. I have now revisited this and built a PCB version, a ZX80 clone I have called Minstrel.

Wednesday, 21 August 2013

ZX81 Clone Part 1

For many years, I planned to build a ZX80 clone. It's all standard parts (no custom ULA like the ZX81 or ZX Spectrum), and it's a well known and well documented circuit. However, I never quite got around to it. And then, I got my hands on an actual ZX80 (read about the repair of the ZX80), so the idea lost momentum.
Recently I've come across a few more ZX81's with dead ULA's, which is great for turning them into ZX81 USB keyboards, but not great if you play 3D Monster Maze. So back to the idea, but this time, make a ZX81 Clone. OK, it's reinventing a wheel that's already been reinvented, but it should be an interesting project, and I plan to make some modifications along the way.
The idea is to build something along the lines of a ZX81, using standard components i.e. without using the custom ULA chip. I've talked about that a few times before, it's basically all the chips on the ZX80 that weren't the ROM, RAM or CPU rolled into one. The ZX81 ULA also added some extra functionality over the ZX80, so it's even more chips to replace. It was a marvel at the time, only problem is they ran hot and eventually failed, and you can't easily get replacements. The inner working are now well understood and well documented, thanks to the work of various Sinclair fans. The following sites have provided excellent points of reference, and are well worth a read:

It seemed the fist stage was just to try to build up the ZX81 circuit away from a ZX81 board, but using the original ZX81 chips. This was just a test of how practical it would be. It worked, not particularly well due to clock issues, but sufficient to move onto the next stage.
This used parts borrowed from an issue 1 ZX81, a Z80 A CPU, Mostek MK36809N (8K mask ROM) and Mostek MK4118N (1K SRAM), and the Feranti 2C184E ULA is the one at the bottom with the heatsink on. The next step was to replace everything but the ULA with modern equivalents. I used a modern Z80 CPU, the Z84C0006PEG (which is limited to 6MHz, I need to order a faster one if I want to enable turbo mode). The mask ROM was replaced with a 27C64 (8K EPROM), and the RAM with a 62256 (32K SRAM). Although it is a 32K chip, without extra logic, only the first 16K can be used. Even though this is more RAM, the supply current is almost half with the modern chips.
I had a few problems with V1 above with the clock, and the same here on V2. I ended up building an Arduino based frequency counter to keep track of the frequency fluctuations. Since the video signal is directly tied to this frequency, if this drifts, the TV signal goes out of range. I tried both a 6.5MHz ceramic resonator on the ULA, and also a 6.5MHz crystal oscillator made with a 74LS04. I eventually traced the issues to the transistor which buffers (and inverts) the clock between the ULA and the Z80 CPU. I tried an assortment of different transistors, including a ZTX313 from a ZX81. I finally changed to using a gate from a 74LS04 inverter, and the clock issues all went away, I got a stable 6.5MHz main clock and a stable 3.25MHz CPU clock. And that lead to a stable TV display.
The video output isn't bad considering this is constructed with long wires on breadboard, with a simple transistor amplifier on the video out, and it is being displayed on a modern LCD TV. Just a word at this point about ULA versions. There were two, the original 2C184E, like the one I am using here, and the later 2C210E. The main difference between them was an improvement to the video signal, adding the missing 'back porch' signal to properly set the black level. So that's about as good as I'd expect from a lashed together circuit with the older ULA.
So now that's working it's onto the next stage....

Sunday, 18 August 2013

Simple Arduino Frequency Counter

I've been having problems with clock drift on one of the projects I've been working on. It's meant to be 3.25 MHz, but it seems to drift down to about 3MHz on occasion. I have been monitoring it on my trusty oscilloscope, but although it can measure frequency if you move the cursors around, it can't keep track of a changing signal. The cursor needs to be moved whenever it changes to check the new reading.
I had a look around at various meters I have, but none can measure frequency over a few tens of kilohertz. I started to consider buying a dedicated frequency counter, but I noticed that some of the cheap ones on ebay looked to be nothing more than a microcontroller and an LCD display. A quick search turned up a number of projects, one of the simplest was a Frequency Counter kit from Sparkfun. This was based on the ATmega328P running at 16MHz, as used on the Arduino. The LCD was a standard HDD44780 based display (as used in my LCD Clocks). The wiring was as follows:
  • D2 - RS (LCD)
  • D3 - R/W (LCD)
  • D4 - E (LCD)
  • D5 - Frequency input
  • D6 - DB4 (LCD)
  • D7 - DB5 (LCD)
  • D8 - DB6 (LCD)
  • D9 - DB7 (LCD)
  • D10 - Backlight Control (LCD)
Other than the usual backlight contrast pot, no special parts were required, so I hooked up the circuit on an Arduino.
The code provided on the Sparkfun site was simple and to the point, just set one of the internal counters to use an external clock (which is fixed as pin D5, so that is used as the input), wait 1000mS and see what it has counted up to. I modified the display code to format the frequency with commas as thousands separators (as 4000000 Hz and 400000 Hz can look the same at first glance, 4,000,000 Hz vs 400,000 Hz should be clearer.
That was all there was to it, the accuracy is reasonable, certainly good enough for indication of the clock remaining stable or starting to drift again. There is no input stage, other than the built in protection on the ATmesg328P, and building things up with long wires and breadboards isn't fantastic when working with higher frequencies due to all that stray capacitance, but it does seem to work quite well. I will probably build this up into a box as it's turned out quite handy, but I think I woudl add a FET input stage to reduce the loading on the circuit under test.
My clock issues have also been sorted out, and work on the other project continues. Yes, the label on the EPROM does say ZX81. More on that at a later date.....

Saturday, 10 August 2013

Free Electric Vehicle Charging Point

When I got my Nissan Leaf (see my Review of the Nissan Leaf Part 1, Part 2 and Part 3), I knew that one thing that was going to be a bit of an issue was charging the Leaf at home. The best I had come up with was using the 'Emergency Charger', plugged into a normal 13A socket and run out of the door.
This wasn't ideal as the charger box either hangs down from the socket, or is precariously balanced on a nearby shelf.
As I'm using this more, I've been thinking about some different options. The first was to attach some sort of cradle to the wall beneath that socket to better hold the charger up. But that would still leave it running under the door. The next option I considered was to get a box fitted to the outside wall with a 13A socket and a space for the charger. That seemed like the best option, but I thought I should have a look around and see what other solutions had been found. During that process, I found that British Gas were offering to install free charging points for electric vehicles. Don't worry, it's not the traditional meaning of the word 'free' on the internet, it is actually government funded, so no cost to me. Other than information, it contains a GSM device which provides information about how I use the charging point. Seems fine to me. They could gather the same information by looking a the back of my house every day and seeing if there car was there and plugged in or not.
The device was installed in the same place I'd been planning to put my box, but is self contained, and wired direct to the mains, so can charge at 16A rather than the approximately 10-12A limit of the 'emergency' charger.
I can then close all the doors and leave the car on charge. No needs to prop the door closed with a half brick, or use extension leads and have to worry about rain.
More details of the British Gas Free electric vehicle charging package. The program is running until March 2015, so get your free charging point now!

The unit really is in exchange for data provided, and unfortunately that means you need to have a good mobile signal at the location you plan to have the charging point installed. If there isn't a sufficiently strong signal, they won't install it, so best check first.

Wednesday, 7 August 2013

OUYA Review

OUYA is a neat idea, it's another in the line of ARM based Android devices, which are essentially an Android tablet without a screen, such as the Raspberry Pi. This one was targeted at the living room TV with a games store and a bundled wireless controller. Netflix and Youtube integration are also apparently on the cards, and there are loads of games to 'try for free' on their store.
What? can't you see it? Well, I pre-ordered one from their website when they started accepting orders for overseas customers. That was on the 11th June. I haven't heard anything from them since then. I've tried email, raising a support case, and even lodged a Pay Pal dispute. However, all I have to show is that empty space and a small but unappreciated dent in my bank balance. I've been waiting as long as possible to give them a chance to reply, but Pay Pal have deadlines for dealing with disputes, if you leave it too long, they won't get involved. The initial case was lodged shortly before the deadline, and it is now time to escalate the case and get Pay Pal involved and get a refund. I'm disappointed that I have to do that, but I can't see any other options.

Update #1:
I escalated the Pay Pal dispute at 07:19 this morning. Just over at hour later at 08:33 I received a dispatch notification. So it took involving Pay Pal to demand the money back to get them into action, but I now have a tracking number. But hang on, what's going on with the tracking?
It appears to have left China yesterday (even thought I only got a dispatch note today?), been to East Midlands airport, then to Hong Kong, back to East Midlands, back to Hong Kong, then onto Dubai and is now in Germany! What are they doing, part funding the project with Air Miles? Is this a joke? I don't know.

Let's see if comes back anywhere near the UK again!

Update #2:
It finally arrived at my door, but UPS requested Cash On Delivery, an additional £28.19 in import duty and 'brokerage fees'. That's almost half the original cost of the unit! Whenever I've ordered from the US in the past, the supplier had added VAT at the time of purchase, thus avoiding this sort of thing. The original OUYA price included US tax and shipping, and there was an additional charge for international orders, which now appears not to have included tax.

Sorry, but after complete lack of action or communication until I tried to claim back via Pay Pal, and now this, I'm really not interested any more. The OUYA might be turn out to be a good product, but I don't I think I'll be getting one any time soon.

Update #3:
Paypal had no response from OUYA, so provided a full refund (less a bit due to currency conversions). Shortly afterwards, OUYA emailed to let me know my console was waiting to be collected at the UPS depot (still presumably with duty to pay). I've explained the situation to them, and I think the OUYA console is going off for yet another around the world trip on it's way back to the suppliers.