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!

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! 

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. 

Building an Altair 8800 Clone.

Having had a bit of a clear out of the workshop recently, I found a very posh (and expensive at the time!) rack case. 

I need something to build into it. Let's re-create someone else's project for a change..

What about a MITS Altair 8800 clone? That would be exciting, and there's a ready-to-roll Arduino emulator available. It really is an extensive project, but using inexpensive hardware. Details can be found here.

So, parts are procured... An Arduino Due clone, a bunch of LEDs and switches.

The original clone project called for a bunch of buffer transistors to drive the LED's, as if they were all lit up, the maximum source current of the Due would be exceeded. I must say, the designer does like to run his LED's at a higher current.But who doesn't like some bright LED's? You could increase the current limiting resistors, and not bother with a buffer, but who doesn't like some bright LED's? The buffer board consists of a lot of transistors. Let's simplify this and use a few 74HCT541 non inverting buffer IC's. We've got more bits than we need.. you never know.. expansion or something!

A PCB is created, and sent for manufacture.. 

Now we're going to need a front panel made, and I used Front panel designer to re-create something a bit like the original. It's sent off to ATP Projects to make it reality. Files for the front panel, and buffer PCB can be found on my github page here.
 

Now, as well as the human/machine interface being handled by the front panel LEDs and switches, it also has a terminal interface. I dislike the idea of hooking this up to a modern computer, running some serial terminal. I'd rather it had an interface of it's own. Now various bits of video hardware are supported by the emulator. I like the idea of a composite output, emulating a old style terminal (I did look, briefly, at procuring an old VT52/100 compatible terminal... whoa, there's some money now!). I can make a serial terminal to output composite video easily enough using Arduino, and to send data from a PS2 keyboard, but there's already a polished, open source solution already out there, courtesy of Geoff's projects. It supports PAL and NTSC and VGA, and emulates a few different terminals. The gerbers are downloaded, and sent for manufacture.

The front panel arrives . It's superb. 

... as do the PCB's...

The buffer board is the first to be populated. 

The LED's are fitted to the front panel and held in place with a dab of adhesive. 

While this is drying, the Due clone is uploaded with the code. You'll need to install any missing libraries, and ensure the version of the SdFat library installed is 1.1.4, later versions throw the error 'File' has no member named 'getSFN'.

The front panel switches are added in...

... and the long, tedious job of wiring it all up...

... LEDs to the buffer ...

... buffer to the Due, with SD card adaptor used as a reader as per the instructions. I hope you like the "mother" board 😆.

Switches connected...  Note the micro SD card adaptor is used to connect SD storage to the Due.

... and a quick test shows some fault finding is needed as a couple of the LED's aren't working, which is thankfully easily sorted. 

Next the video interface is built up, and programmed with Pickit 5 (Graham's design uses a 32 bit PIC microcontroller)

 

The MPLAB IDE faultlessly uploading the firmware.

In the interim period, I'd managed to get hold of a small black and white CRT monitor on Facebook Marketplace, for peanuts. I'd tested it, and it performed well with a test pattern from the video rack. Thanks Colin! 

It's not got a makers name, but I'm thinking it may be a Hitachi or Shibiden. 

It's vintage and looks the part... 

Hooking the output from the PCB to the monitor and switching on produced less than encouraging results. If you look carefully, you can *just* make out some text in the top right of the tube ... and why is the line sync showing up white?? 

Reversing the video connection solved the issue. Serves me right for using the wrong type of socket! 

... and once a compatible keyboard is located, RX and TX pins shorted together to get an echo test to work ... 

Brilliant. Now to connect it to our Altairduino!

The RX & TX lines are connected to pins 18 & 19 of the Due, and the unit powered up. With a serial terminal opened via the USB port on the Due and my PC, the Stop and AUX1 switches are raised to put the unit into config mode, where the default serial terminal can be moved to pins 18 & 19. Don't forget to save as default! (If you do this without an SD card present, the default settings are saved to EEPROM within the Due. If you subsequently fit an SD card, the process will need to be repeated, as the default is then saved to the SD card. 

So far the machine has been running from 5V supplied by my bench supply. A simple power supply is built up on a piece of perfboard. It's a rectifier, some smoothing and a 7805 regulator. LEDs are added to the input and output, just because ... 

A suitable 6V transformer is mounted into the enclosure, along with the supply board, and connected up .. 

Mains will eventually be supplied via an IEC connector on the rear panel.

I want to replicate the Altair badge on the front of the machine, so I order a piece of thin aluminium, cut to the required dimensions by eBay seller Penninehardwaredirect. Just message them the required size, and they do the rest. A first class service. 

I spent a while searching for the right sort of font, and 256-bytes fits the bill.

It's flipped to mirror image and laser printed onto some glossy photopaper, and that is then ironed onto the aluminium strip, with the iron on the hottest setting. It's exactly the same procedure as making a toner transfer PCB.

Soak off the paper... 

... and give it a light coating of clear protective lacquer...

.. and stick it to the front panel with some contact adhesive. Smart.

A back panel is fabricated from aluminium to (my now) legendary high standards (ahem). It's not from this rack unit though, and this rack doesn't appear to have any means to attach a back panel....

So some doo-hickies are drawn up on CAD, and 3D printed....

... and pressed into service ... 

Nice ...

The back panel is secured into place, and I'm thinking it's finished. I was wrong. 

The keyboard interface isn't working. It was previously working fine. Doing a loop-though test, the terminal appears to be sending data, and that's confirmed with the oscilloscope.... Some head-scratching occurred... Also another weird thing was happening. Any traffic on the USB com port of the Due was being relayed to the terminal board via pins 18/19. The Due was erased and re-flashed. Same weirdness... It's also refusing to read the SD card... 

A replacement (genuine this time!) Due was ordered,  and some aspirin to cure the headache caused by the wiring, and this sorted the issue.

I also ordered an SD extender , and used this instead of the adaptor. I can conveniently locate the SD card reader on the exterior of the case now. 

Right... I'm off to see if I can complete Infocom's hitchhiker's guide to the galaxy!