62256 SRAM Tester

If you've been my youTube channels lately, and following the VIC-20 story, you'll know I built a Hyper-expander. You may have also noticed that it didn't really get used much in the repair video. There's a reason for this.... 

It didn't work.. 

Even once the VIC-20 was repaired, nothing I did would get the VIC to recognise more than the 3K extension. The EPROM wouldn't load at all. 

Investigation required. 

The cartridge was pulled apart , the EPROM checked, and the two 74LS148 gates. I wish I'd socketed everything! The EPROM and the two decoders proved innocent.  

That leaves the 62256 RAM IC's. 

So, how to check them?

I could pull the ZX81 apart, and test them in there, but we can't access the full 32K.

SO, inspired by the 2114 tester I constructed for the 2114 SRAM during the VIC repair (https://github.com/skjerk/Arduino-2114-SRAM-tester) I decided to have a look for an Arduino based tester, whilst there is a version for an arduino Mega, I don't have one to hand. The issue is, a normal Uno (or any ATMega328 based Arduino) doesn't quite have enough pins. We need 15 outputs for the address bus, and 8 for the Data bus. Two 74HC590 counters are fielded in to drive the address bus from just two pins (clock and reset).

Here's the theory of operation. The Arduino resets the two counter IC's to 0, by pulsing D3. A pattern of data is generated sequentially between 0b00000000 to 0b11111111 and written to the first address. It's then read back, and compared with the written pattern. If all is well, then the address is incremented by pulsing D2 and the procedure is repeated. If the pattern is not read back correctly, the fail LED is lit, and a message with the error written to the serial interface, but the test will run until all addresses have had all patterns written and read back. It takes quite a while to run.

While the test is running, both PASS and FAIL LEDs are illuminated. The green LED I added to pin 2 of U2 (via a 1K resistor) to provide some indication that the test is running, if no terminal is connected. 

Normal running looks like this on the serial interface.

62256 SRAM Tester by Doz.    

Running test pattern 00000000

Running test pattern 00000001

Running test pattern 00000010

Running test pattern 00000011

Running test pattern 00000100

Running test pattern 00000101

Running test pattern 00000110

Running test pattern 00000111

...

Running test pattern 11111110

Running test pattern 11111111

All tests complete 

PASS

Hit reset to re-run

a failure looks like this:

ERROR at 0x5A64 - Got: 01100001 Expected: 01100010

The code can be found, as usual, on my github page.  https://github.com/andydoswell/platformio/tree/main/Projects/62256%20test 

Please note this is a PlatformIO framework project. You can probably clone the git, and pull main.cpp out of the SRC folder, and rename it .ino , and it'll probably run on the Arduino IDE, although I haven't tried it. 

To cut a long story short the RAMs were innocent, the fault was back in the VIC-20 itself, but at least we have a device to test them now!

The future?

Dear reader,

You may have noticed that over the last few months I've been rather active on YouTube. I'd neglected the YouTube channel to be honest. It takes a lot of effort to make a video, it's not just the filming, but the editing, rendering, uploading, dealing with the odd copyright hassle, etc etc.

I find it much easier to take a few photos and write. 

Back just before Christmas time, there was a slight change in my career. It involves me being in front of a camera, presenting technical stuff, as well as my engineering duties. This didn't initially sit well with me, so I thought I'd get some practice in and rejuvenate the existing "Doz' Television Workshop" YouTube channel. 

Well, it's gone all a bit better than expected. Each video I've done on Doz' Television Workshop has gained me subscribers (and lost the odd one or two along the way), and I get way more "views" than I do hits on this website. This has soaked up a lot of my time. 

So, what's the future?

I don't want to neglect the website. It's like an old friend, I thoroughly enjoy writing, and I don't want it to just become a list of my YouTube videos, and indeed, from now on, I won't just post up links to videos. If you want to watch my videos, just hit the subscribe button, if you don't, that's fine.

I think this site has a future with design projects (and, in fact there's a few in drafts), that may have accompanying videos, maybe not so much the repair and restoration projects. 

I have really enjoyed channels like Noel's retro lab, ojnoj. Irish Vintage TV and Radio, Shango066. These videos tend to be longer than many, I find myself absorbed by them. It's a community I want to be a part of. In the day job, our marketing dept. tell me my videos should be "around 10 mins" ... well, I can't see that happening here! There's just no way I can do an in-depth diagnosis & repair in just a few minutes, and I won't try. To be honest, it's something the website doesn't convey. The actual length of time it takes to do these things.  

This isn't about money. This website carries a few adverts, and, in it's entire lifetime hasn't earned me £130 in revenue. My YouTube channel can't be monetised (as yet), I simply don't have enough subscribers. Let's face it, I'm never going to retire on this. 

This isn't about my ego. Yes, I get a kick out of someone watching my video, but it's in the hope they found it educational, or at least entertaining. It's about sharing.

Let me have your comments. 

Yours Aye,

Doz.

The return of Ian's Leak Stereo 20 and Varislope 2

Ian's had some problems with the Leak gear I did a year or so ago...

Here's a couple of videos of the repairs. 

Solar lighthouse garden ornament - A design that could never work.

About 12 months ago, the long and suffering Mrs Doz bought me a solar powered garden ornament, in the shape of a lighthouse. 

It's got a white 5mm LED, which is situated inside a rotating silver reflector. Quite a nice touch, and more effective than just a simple flashing LED... except it never worked properly. 

There's a push button switch on the lamp housing, which switches the unit on. After dark, the LED illuminates. Once. 

The following day nothing happened. 

It's not worked since. 

So I disassembled the lamp house to see what the fault was. It consists of two parts, the top part consisting of the solar panels, a charging circuit and LED driver, and a lower part with the motor and it's gearbox, and a 600mAH, AA NiMH cell. 

I popped the cover off the motor unit in an attempt to find out what the problem is.... and spot it straight away. The motor is connected via the push button switch, straight across the battery. As soon as it's switched on it will start turning, and eventually discharge the battery. The solar cells aren't big enough to keep the battery charged up enough. What a silly design. 

I was hoping that the LED driver in the top would be able to provide a suitable switched supply to the motor in a similar way to the LED, but alas no, it's got a small flyback converter to provide ~2.1V to drive the LED. 

So, a plan is hatched... 

A separate solar cell, and battery connected by a wire to the motor unit. 

Recently we had to replace another solar light in the garden, after it was damaged over winter. This has yielded a nice solar panel and it's fitted with a single AA NiMH cell, excellent. The battery is tested, and looks to be in reasonable condition. The control electronics in this enclosure are removed (again, it's a flyback converter)

So we need a circuit to charge the battery during the day, and switch on the motor at night. 

The solar cell charges the battery via D1, a BAT43 small signal Schottky diode (a strange choice, but it's rated to 200mA, which is more than the charging current capable of being delivered by the solar cell, and it'll have lower forward voltage drop than a normal silicon diode), which prevents the battery discharging into the solar cell at night. When the cell goes dark, Q1 loses it's base bias via R1 &R2, and switches off, which causes the voltage at it's collector to rise. This in turn switches on the base of Q2, which causes it to conduct and switches on the motor. 

After a bit of experimentation on some breadboard to get the values of R1 & R2 right (this effects the threshold where the unit switches the motor on), it's built up on a bit of perfboard, and fitted inside the enclosure.

After sealing everything up with some liquid rubber, it's taken outside ...

Now just to wait for nightfall...

Further experiments & improvements to the Arduino Geiger Counter

My dad recently returned from a small socially-distant holiday to Cornwall.

"I've bought you a gift, saw this and thought you'd like it!"
"The chap in the shop said it might be a bit radioactive" *

It's a "Radio Compass" from an aircraft. This is used to display a heading to a terrestrial radio beacon. This one's old. Old enough to have a Radium-266 dial. Waving the geiger counter near it proves the point, end-stopping the meter on both the SBM-19 and SBM-20 tubes. It does show a potential limitation in my counter though.. let's investigate....

The original project is here

The count rate appears to be being limited to a shade less than 1000 CPM. by something. It could be the tubes are saturated. It could the arduino is not capable of counting that quickly. It could be the high voltage supply is incapable of delivering that amount of current when the tube is at a high pulse rate, and the HT is falling between counts.

After poking round the high voltage supply, I think we can conclude it's not that ... 

There IS a delay in the tick function of the sketch, and also digitalWrite is notoriously slow.

After modifying the sketch , there's no detectable change, even with that delay removed, which IS still blocking the sketch. 

Looking closer on how I can get the loop to run faster, I'm unnecessarily updating the LCD every cycle, and reading the battery every 5mS ...

 ... this is moved into a non blocking loop counter, to update every ~3 seconds or so ..  

Oh that's fixed it ! I'm now getting a reading of ~30,000 CPM maximum from my radium dial... 

I also needed to tweak the meter movement routine a shade to compensate for the faster loop speed.

The new sketch can be found on my git as usual https://github.com/andydoswell/geiger_counter

*The chap in the shop also told my dad the chap he bought it from had a stack of them under his bed... I'd hate to see what his dose rate is like! 

Garmin HUD & ESP 32 stand-alone module.

A couple of years ago I upgraded my mobile phone, and was dismayed to find Garmin no longer supported my much-beloved HUD (Heads up display), rendering it redundant. It was only 7 years old at the time... is that acceptable product life expectancy? Gutted. 

I seem to remember reading somewhere that the same display was built into BWM cars ... are BMW owners in the same situation?

It featured in my Mini speedo video here. 

Thankfully, someone had reverse engineered the bluetooth serial protocol used to control the device. 

The original work was carried out by gabonator (here), Frank Huebenthal and subsequently by skyforcetw (here). Stunning work. Skyforcetw had even written an android app to interface Google maps to the Garmin HUD, excellent. Except nothing I could do would persuade it to run. 

So I tried skyforcetw's arduino library, and attempted to load it into an ESP32, and tried to modify it for SerialBT. After a lot of debugging and chopping of code from Frank Huebenthal's work, I finally started to get some meaningful information displayed on the HUD. 

So, after this success, a plan was hatched. I just want some meaningful info displayed. I'm not particularly interested (nor capable of) writing something for my phone to run , so I'm thinking about a simple speed display, and maybe some other info.. 

So a UBlox GPS module (this one's an M7, but it will work fine with the cheaper M6)  is hooked up to the ESP32's Serial 2 port on pins 16 & 17, and to the 3V3 and GND pins. 

I recycled my sketch from way back, which was used to configure the GPS receiver in run-time (you can, therefore, use the slightly cheaper module without the battery) and then set about working out why I couldn't get the GarminHud library to run. It turns out that SerialBT's write command isn't quite implemented correctly, so I modified the SendHud function to utilise print instead, which worked.

Version 2 of gabinator and Frank Huebenthal library features a "Down" arrow, which would allow me to implement a GPS compass using the direction arrow function. A gps clock is implemented, a speedometer (in mph, but easily changed to Km/h or knots should the need arise)  and a display of the number of satellites in view (and a warning of no GPS lock) 

There's a slight issue when drawing an "up" arrow. Whatever is written next to the direction display is ignored! This slight bug is overcome by simply writing anything other than "up" twice! 

The sketch (and the required GPS library) can be found on my github here.

The unit is mounted in a box, along with a simple 7805 power supply, and trialled. 

Here's a video of the unit in action. 

... another saved from landfill! 

Wurlitzer 200A electronic piano repairs.

Ah ... another YouTube thing ... a two part thing this time! 

Enjoy

Pye 169 revisited.

Remember the Pye 169 back here?

 
Well... it's been acting up. Rather than the usual write-up, here's a bit of video entertainment, also ideal as a cure for insomnia...

 

Enjoy ... ! 

Commodore 1541 Floppy Disc Drive repair.

I bought a Commodore 1541 floppy drive on eBay... not just any 1541 ... oh no... a broken one.

Apparently it was also used as a prop in a film.. http://www.computinghistory.org.uk/pages/50703/Bandersnatch/

Anyway, it doesn't work. No power.

Cursory checks to the input fuse show that's intact, so caution is thrown to the wind and mains applied... the over current trip on the bench pulls straight out (it's rated at 10A)

Checking the input fuse shows it to still be intact ..?

Ah well, in bits with it... 

Removing the main PCB allows access to the transformer etc .. 

... but what's that goop on the bottom of the PCB? 

It's waxy ... 

The mains power input couldn't be simpler. IEC Socket, fuse, switch, transformer... 

... the red seal on top of the socket looks  to have "burst" ... is that the source of our waxy goop, and excessive current draw?

Removal of the lower part of the case, and lifting the chassis out, shows more goop, right by the socket. 

The rivets securing the socket are drilled out, and it's removed.

Looks like the internal filter failed and got excessively hot at some stage, and melted the insulation. It measures a short circuit between live and neutral! A new filtered socket is obtained...

.. and duly fixed into position with some M3 fasteners. Finding a shorter socket is essential, there's just not enough room for one with tags. 

And powering up gives us the familiar sequence of LEDs, and a spinning disc. 😊

Now what's needed is a C64 or VIC20 to test it ... hmmmm ...

ESP32 Big Filament YouTube Subscriber counter

Now I've made a couple of new YouTube videos (one's not quite published as yet) I thought I might like one of those counters, that people have in their videos... Techmoan has one... 

It would seem sensible to utilise the big filament clock display... 

So there's some different code at https://github.com/andydoswell/filamentclock... 

There's no change to the hardware.

If I ever get to 10,000... I'll need another digit.

ESP32 Big filament clock

Inspired by one of Big Clive's YouTube videos (see here), I fancied doing something with the LED "filaments" you can get from AliExpress. 

I fancy making a big 7-segment display clock. 

Some where duly ordered up, and arrived some time later.

Now they need around 47V to light... and (allegedly) 30mA , but experiments show they are more than bright enough at 3.3mA for our purposes...

So, let's make a clock display!

Problem no 1: The power supply. 

Unlike Clive, I'm not going to run the clock off rectified mains ... I did contemplate a capacitive dropper, but, again, it's not safe. 

A quick dig about in the junque box did provide a couple of suitable transformers... one with 18-0-18 and one with 15-0-15, with 220V primaries. As we are normally somewhat above 220V here, and the secondary will very lightly loaded, these would probably do, and some tests are run. Getting an low voltage output to run the micro will mean another transformer ...

The I though about using one of the ebay buck-boost modules... except for they top out at 35V .... or do they?

Now the module is based on the LM2577_ADJ. Shown here in it's boost configuration. R1 on the module is a 10K multi-turn pot, and R2 is a fixed 360 ohm resistor.  

The output voltage is controlled by the feedback pin, so that the feedback pin is always at 1.2V. The module differs from the schematic shown here, as it has two inductors to allow for buck and boost operation, but the voltage feedback section remains the same.

 A quick calculation shows that making that resistor 250 ohms would give us an output voltage of 50V. The existing R1 is removed... 

... and replaced with a 220 ohm resistor soldered to the rear. 220 ohms will allow us some adjustment. 

The output capacitor is removed, as it's only got a 35V rating.

... it's replaced with a 100uF 63V part.

The module is powered up and adjusted for 50V

And a filament is tested. The unit is being powered from 5V, useful, as I can power the whole thing from a 5V wall wart. 

To keep power consumption down a bit, I'm going to multiplex the display. It also reduces the wiring somewhat. Each of the 4 digits of the clock will have it's own anode supply, with only one digit ever lit at a time. This allows us to connect each of the segment's cathodes together. 

The anodes will require a high-side drive, that will happily hold off our 50V. After looking around in the transistor box, it looks like a 2N7000 will do. It's a 60V FET. We'll need two per drive. I've got a load of them, and they're cheap. 

The micro's 3.3V high signal comes in via the 10K resistor, and switches on the lower 2N7000. This removes the gate signal from the upper 2N7000, and removes the anode's supply. The two resistors (100K and 47K) are there as a potential divider, so we do not exceed the maximum gate-to-source voltage of 20V. We'll need to remember the logic is inversed, input of high turns the output low, but we can sort this in software. 

It's built up and tested on a breadboard. 

For the cathode drive, we can use our old friend the ULN2003 (just, it's rated to a maximum of 50V... we could have used individual transistors again, say the 2N7000... anything rated to 50V would have done) 

The micro's inputs come into pins 1-7 and the output to each cathode via it's own 1K current limiting resistor. 

Excellent.

We'll use the ESP32, as we can utilise it's Wifi to get the current time via NTP, and it has it's own RTC. It's proved excellent in the ESP32 analogue clock. 

The end schematic is rather simple. I've added switches for wifi reset (more about that later) and 12/24 hours, and an output to drive the colon separator between the hours and minutes.

I did contemplate a PCB... but it's quite simple, so it's implemented on a piece of perfboard.

So, how to mount the filaments? 

Fusion 360 is fired up, and a design created. 

It's just a bit too large for my 3D printer, but it should be OK... 

I did have to scale it slightly to fit on my Anycubic Mega S, a friend of mine has a Pursia, and he rekons it'll fit on that if this works out too small. Anyway, it's printed, and sanded back to get rid of any lines, and painted with a little high-build primer. 

and finally finished in a bit of satin black. 

The LEDs are tested on the bench supply, some are intermittently faulty, or just dead.

Each filament gets a couple of wires soldered to each end, and threaded into the back... 

Much tea later ... 

The filaments are quite fragile, and I lost a few along the way... 

A couple of warm white LEDs are inserted to form the colon, and everything sealed into place with a dab of RTV. 

The whole thing is wired up ... each digit's anodes are connected together, and each segments cathodes are connected together..

What a rats nest !

The software owes a lot to the ESP32 analogue clock from earlier in the year. It still uses NTP to acquire the time, and uses the ESP's in built RTC. The new parts are a software multiplexer for the display... it goes like this....

1. All anodes off.

2. Set cathodes.

3. Switch on one anode.

... and repeat until the display is complete. It's identical in principle to the display driver for the STD305D turntable The ESP32 is more than capable of doing this faster than the eye can make out (in fact, it's capable of doing it FASTER than circuitry can switch the LEDs on, so there's a delay in the programme to slow it down!), so it just looks like the whole display is lit. 

The other nice bit about the software is the use of the WiFiManager library, which gives us an easy way to connect to wifi without all that tedious hard coding. That's also why I've provided a reset button, which erases the WiFi credentials, and resets the unit, so you can add a new SSID, if yours changes or you move the clock to another location with a different SSID.

Power consumption of the running clock is a bit over 250mA 

The software, as usual can be found on my git, along with the 3D model for the back panel. 

https://github.com/andydoswell/filamentclock

WiFi Manager in use ...

Just for fun, I did run one of the filaments at 30mA just to see what would happen... 

It was incredibly bright ... and lasted for about 30 mins before starting to flicker, eventually going open circuit after another 20 minutes.