Friday, 8 December 2017

Arduino EEPROM Programmer

I saw this kit advertised on Tindie (Simple EEPROM Programmer shield for Arduino Mega) and thought it looked interesting.
I have an upcoming project where I will need to program some EEPROMs in place in a system. I hadn't looked into the programming algorithm, so this seemed like a good way to start.
The kit arrived, very nicely presented with a clear double sided instruction sheet and a nicely laid out board with all the tracks on the back and a copper pour ground plane. I notice things like that. I like things like that.
Assembly was straightforward. I chose to fit an IC socket (I had already stolen the ZIF socket supplied with the kit for something else), as I wasn't planning to change the IC in it very often.
All that was needed was to plug it into an Arduino Mega. The firmware is available from the author's blog. We've all had fun in the past with Arduino code that doesn't build and needs specific old versions of certain libraries, but I am pleased to say it built and programmed fine.
It uses a serial protocol, over a 9600 8N1 connection. The commands are detailed in the code, but basically V shows a version string, Raaaa reads from address 0xaaaa, and Waaaa:dd writes data 0xdd to address 0xaaaa (can be multiple bytes e.g. Waaaa:dddddd).
You can drive this from the serial monitor, but there are two provided front ends, a command line version and a desktop app.
Testing this with a couple of Atmel AT28C64B EEPROMs that I am currently using a lot to test a Commodore 64 cartridge. Yes, I have put labels on the chips, the etched labels can be tricky to read at some angles. No, of course my eyesight isn't getting worse, of course I'm not getting old.
I was able to read in data from the chip fine, but writing didn't seem to work. I checked with the author and he was using the same chips as me, and they were working fine for him. I checked the chips I was using in my usual programmer, and they were programming fine. It was then I noticed the lines about "Software Data Protection".
Checking the AT28C64B datasheet, it seems there is a sequence of instructions that can be sent to the chip to lock it to disable future writes, and to unlock it again. My Minipro programmer was unlocking at the start, programming and then locking again. A sensible precaution against accidental writes.
I tried removing the SDP (Software Data Protection, not the Social Democratic Party) and was then able to successfully program using the Arduino based programmer. There was no code present in there to do SDP which explains why it wasn't working on chips I had already used with my EPROM programmer. I had tried a chip fresh from the tube, but stupidly checked that it was working first by programming it on my EPROM programmer, which locked it. As there wasn't any provision for SDP in the code, so I tried enabling it using write instructions, W1555:AA, W0AAA:55 etc. but that didn't seem to work.
Checking the datasheet, they specified a series of events, so I took the V0.01 code and built a V0.02 with SDP enable and disable built in, trying to follow this sequence. This didn't work either, I tried a few ways around it, but thought it may be timing related. The exiting code has an overly generous 10mS write pulse, which is actually the maximum the chip can support. The datasheet says the chip can work with a pulse as small as 50nS. I tried a 1uS pulse (using the Arduino delayMicroseconds function), and that worked. I left these are separate commands, as they probably only apply to Atmel chips. P to protect the chip, U to unprotect.
The sequence above show testing writing is working, enabling SDP and writing more. Those writes didn't appear. Enabling SDP and repeating and the writes are now retained. Note the first byte is overwritten with 00 during the lock / unlock operation. Some data needs to be written to any address to complete the lock / unlock process. A future improvement may be to read that byte before lock / unlock and write it back afterwards with the original value. There is also a function to erase the whole chip, but that requires a 12V pulse which is not easily available in this case.
So, I bought this kit to learn more about programming EEPROMs, and it certainly worked. I sent my updates to the author, and he has already incorporated them into the official V0.02 release (available on his blog).

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Sunday, 26 November 2017

Blank ZX81 membranes and overlays

My Minstrel ZX80 clone kits and ZX80 membrane overlays are now available with a new type of ZX81 replacement membrane.
These are the same size and function as the ZX81 versions, but are slightly thinner and are plain black rather than having the ZX81 keyboard printed on them. They are produced for me by RWAP (who also suggested the idea), so are the same top quality as their ZX81 replacement membranes.
As with the ZX81 version, these membranes have a 3M self adhesive backing.
When removed, that shows the matrix off nicely. The ZX81 version has a white background, so you don't see the matrix as clearly. Not that it matters as you normally attach that straight to a ZX81.
However, this looks great on the underside of a Minstrel clone on a clear perspex sheet.
If you wanted to, I suppose you could use one of these to create a stealth ZX81 or TS1000.
However, in practice, you probably want to apply a stick on keyboard overlay.
And then you are back to a TS1000 with a working keyboard (complete with the TS1000 labelling which differs from the ZX81 on a couple of keys).
I have been using these on the Minstrel ZX80 clones I build in white ZX81 cases. I usually start with pretty beat up ZX81's.
Sanding the top gets rid of the scratches and dings and the raised ZX81 logo.
With these blank membranes, I have been fitting them before painting, to give a cleaner line around the stick on overlays.
You then end up with a stealth ZX80, although as before, you probably want to fit an overlay.
Available with keywords for either the original 4K BASIC
Or the ZX81 style 8K BASIC.
Finally, back to the open frame version of the Minstrel clone.
As requested by a previous buyer, this can be supplied with both overlays and both versions of BASIC so they can decided which one to use.
All these things are available now from my Tindie store.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Sunday, 12 November 2017

ZX Spectrum Issue 2 Colour Adjustment

One of the common problems you see on Issue 2 ZX Spectrums is poor colour adjustment.
This usually results in a very yellow, or very blue screen, or something in between, but usually with a strong tint of one colour or the other.
Issue 3 and later Spectrums have automatic adjustment in the ULA, but issue 1 and 2 boards suffer from this issue. The colour balance is adjusted using two potentiometers on the board, and these adjust two bias voltages, which should be the same but the inverse of each other (i.e. -50mV and +50mV).
You can do this by eye, but just turning them and watching the screen, but I always end up where it is just about right but keeps cutting out to black, and either side jumps to bright yellow or bright blue.
This issue 2 board is like many proving difficult to adjust that way. Many people seem to advise replacing all the electrolytic capacitors at this point. I'm never convinced that recapping is necessary. There are definite cases where it should be done, but in many cases I have found the capacitors are often fine, within spec, often higher than rated and not too high ESR.
As an example, the large 4700uF capacitor in the power supply is reading over 5000uF and 0.04 ohm ESR, which is fine. You could argue it should be replaced, but only if the replacement is at least as good and likely to last, I'm not sure many modern capacitors are as good as the originals were. You see them failing so often in switch mode power supplies in consumer electronics kit. If you do find a low one, then yes, that is worth replacing, i.e. this one is reading low, so I did replace it.
Here I have tried a few things, just to make sure they didn't affect the adjustment process. The 7805 regulator was showing signs of rust, and they run hot, so I have replaced that with a switching regulator.
The issue 2 boards have the regulator on the bottom right, shown here with the heatsink removed. I did clean off the rust, but decided to replace it anyway. The normal switching regulators I use are slightly too tall, so I mounted one on it's side, soldered to a pin header.
That hasn't made any difference to the colour adjustment, when I was running from a regulated bench supply, but I didn't notice the reduction in load of the switching regulator vs the original linear one did make a difference when running on a Sinclair power supply.
I remeasured all the voltages, all seemed fine, but I decided to do the recapping anyway, almost to prove to myself that it wouldn't make a difference to the problem at hand, but is probably beneficial in the long term.
I also replaced the switching transistor TR4 as they are prone to fail. Note also C46 is marked with the + at the wrong end on these boards. It is show correctly fitted, it should be the same way around as C27 on the other side of the keyboard socket.
I had tried this via the RF and then via a simple capacitor composite video modification.
This is normally fine on a later Spectrum, but I have had problems with issue 2 boards before, where you get tearing at the top of the screen, particularly on darker screens such as the DivMMC future menu.
To get around that, I fitted a TFW8B video buffer board to the modulator to give a better composite video output and that straightened out the distorted screens.
After all that, it is still proving difficult to adjust the colour either manually, or via the official method of adjusting VR1 and VR2 to get +/- 50mV.
I had a look at the video waveform on an oscilloscope and you can see how noisy it was. I found that adjusting VR1 one way made this a lot worse.
Adjusting it the other way it was possible to minimise this noise, and the same thing with VR2, until finally it was adjusted down to get the signal as fine as possible.
When that was done, I was rewarded with a solid, stable, and very white picture on the TV.
I dug out an 'untested' issue 2 board without being recapped or composite modded or anything and tried this adjustment method, and got a good result straight away. I think it's scope based adjustments for me on issue 2 boards from now on.
Testing on various games and soak testing this was fine, although I noticed it needed readjustment when moving from a regulated power supply to the standard unregulated Sinclair supply, but continued to be fine on that over a long soak test.
As ever after a repair like this I have the horrible job of having to test out various games to make sure they play correctly. Ah well, it's a hard life.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.