Sunday, 31 March 2019

SD2PET - pre-order

For quite a while now I have been working on a new SD card disk drive for the Commodore PET series of computers. This is SD2PET, and it's available now to pre-order.
It seems like my bench has been covered with scenes like this for ages.
The SD2PET is styled along the same lines as the SD2IEC device produced by The Future Was 8 bit, but has a plug on the end for the PETs IEEE-488 port and datasette for power.
The SD card end will sit neatly by the side of the monitor on your PET, or by it's side.
The custom moulding for the IEEE-488 port and the additional manufacturing processes necessary to build the SD2PET mean the price of this one is going to be slightly higher than originally planned. Since we want as many people as possible to have one of these SD card drives, I've designed an alternative version which much the same functionality, but with less elements.
This has been named the SD2PET Future, and plugs directly into the back of the PET IEEE-488 port, with an additional connection to the Datasette port for power.
We are expecting there will be sufficient interest so that both versions will be going into production. The SD2PET (the external drive version) has been renamed SD2PET+ to differentiate it from the SD2PET Future. They are available to pre-order now, shipping late Q2 2019.

There will be more information on the features and functionality in a future blog post. I just wanted to get this one out there with the pre-order links for those who have been clambering to get one since my PET microSD went out of production.

(N.B., yes, some of these photos are mock ups, we haven't got the final mouldings yet, that's why it's a pre-order and not on sale yet)

Wednesday, 27 March 2019

ZX Spectrum +2 Grey Repair - Working but with screen corruption

Here is a slightly unusual ZX Spectrum +2 128K, the grey model. It appears to be running, but there is noise on the screen when it is working.
The noise doesn't appear to be analogue in origin, it is very clear regularly repeating patterns, and they stop when you hold down reset. Quite strange.
Normally when you see screen corruption like that on a Spectrum it is a RAM fault, it is in the shared memory bank that provides both the screen RAM and the lower 16K. That means the Spectrum doesn't usually work.
This one is a little twitchy, some things aren't running, but running the same thing from a ROM appears to work better.
And indeed this memory tests pass.
As does the other one.
So, I was less inclined to think this is a memory problem. (I was wrong, but please don't judge me). The 128K has a lot more going on inside that the original 48K machine, but still has a lot in common.
I had seen something similar on a 48K Spectrum, there it was a problem with the multiplexor chips which switch the RAM address lines between the Z80 and the ULA (which generates the screen display).
On later Spectrums, and the Grey 128K, the multiplexor chips are combined into a single 40 pin package, here marked PCF1306P. I desoldered and socketed that, and tried a known working MUX chip (a later Amstrad 40058 version), but that didn't make any difference.
I also looked at a few other chips involved in the multiplexing circuitry, before accepting that it probably wasn't there.
Maybe it was the RAM then? Even though it was passing RAM tests? I decided to get a second opinion before starting on the RAM.
Brendan Alford (the author of the ZX Diag software I had been using for testing) confirmed the RAM hypothesis (and referenced an article he had written about ZX Spectrum RAM faults). He even pinpointed the problem chip for me.
IC26 is bit 6 of the lower bank of memory (which is shared between the CPU and the display). You can see for looking closer that all the lines are on the second pixel along on each character. The rest of the characters are fine, although the background brightness changes (which is also controlled by bit 6).
I removed IC26 and replaced it with a known working chip. I didn't have the same speed (150nS) to hand, so I used a faster 120nS chip.
Success. The corruption has gone, so it seems the RAM was woking fast enough when the CPU accessed it, but not quite fast enough for the video RAM. Most of the Grey 128K machines I have seen had 120nS RAM, so maybe they changed to that later on.
This one now has the single 120nS chip, and the rest still seems to be coping fine after a soak test. I wouldn't normally mix speeds, but you can get away with it as long as your replacements are not slower than the originals.
That seems to have fixed it. Can't say I've come across a RAM chips which was right on the edge of failing, but still just about running OK at slower speeds.
Time for some more testing with the built in tape drive, and a divMMC future.

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

Sunday, 10 March 2019

DivMMC Programmer Joystick Tester

The Future Was 8 bit has posted a couple of pictures of a nice new board with lots of flashing lights on recently, so I thought I would tell you more about it.
This board is used for testing the DivMMC future joystick ports. It sits on top of four DivMMC future devices, plugged into the four slots of the DivMMC future programmer (read all about that in it's own blog post).
Just a quick update on that first. It's been doing very well, testing every single DivMMC future that leaves the Pink Windmill, and there have been rather a lot of those.
However two years of heavy use is taking it's toll on the edge connectors, some of which were worn through to the copper in some places.
The boards used here were grey Spectrum 128K +2 boards, all of which were rescued from the junk pile (there's a blog post about them as well). They were all still working (they grey's are a pretty solid design), which is great. It would be a shame to have to replace them, so I designed a PCB which was basically an edge connector extender.
This is soldered onto the original connectors and presents a new gold plated edge connector, which will hopefully give many more years service - and if they get worn out, can be removed and replaced with a new extender board.
So, there are four Spectrum boards. Attached to those are the four extension boards. Plugged into those are four DivMMC future boards.
When plugged into the Spectrums, those boards are programmed (using software loaded from an MP3 player in the programmer box - you did read the previous blog post didn't you? keep up!).
The programming / testing process involves programming the firmware into the EEPROM onboard, and test loading some programs, including on which tests the joystick port.
Here the micrcontroller in the programmer box generates a series of actions on the joystick port. All 32 possible inputs (including the impossible ones like up and down at the same time), in sequence, with release inbetween to check for latching etc. (up, nothing, down, nothing, up and down, nothing etc.)
The software for the Spectrum end is loaded from the SD card by a series of automatic key presses generated by the micrcontroller in the box (are you impressed yet?). It will wait until it receives all of these in the right order and declare a pass or a fail on the joystick port.
In the original build a few years ago, a small blue box was constructed which was called the "joystick duplicator". It's job was to take the input from the microcontroller, which was a single joystick port, and apply those actions to all four ports, keeping them isolated from each other. (if you connected them in parallel, a short on one would cause all four to fail).
This small blue box was not bigger on the inside, anything but, so it had a miniature masterpiece of electronic assembly by TFW8b, following my design which was basically a 7404 driving five 4066 chips, each gate of the 4066 representing a joystick button.
The four cables coming out of that box plug into the for divs under test. I think these were salvaged from dead joysticks by the look of it.
This has also preformed great service over the last few years, but the joystick cables are getting a bit flaky and replacing those would require rewiring inside that box, so I designed a new version, this time on a PCB.
The design was simplified slightly. The original had used 4066s to give a little isolation in case the final design ended up having separate power supplies for the devices being programmed. I think we were considering using Spectrum still in cases at that point - presumably before I added the bit that 'pressed keys on the keyboard' (also using 4066s), which removed the need for keyboards and allowed the four units to be sandwiched together.
The new design uses 7407, open collector buffers. These will short the joystick inputs to ground when the inputs are low, and floating when the inputs is high (they will be pulled up by the resistors inside the divs, as would a normal joystick). That reduced the chip count, so there is just one for each port.
The board sits on top of the DivMMC boards, plugged into their joystick ports (which also serves to keep them vertical, and reduces wobble on the edge connectors). The screw threads on those connectors was the UNC 4-40 style used on D connector jack posts, so they had to be tapped to M3 to receive countersunk screws to hold them firmly in place.
The input connector is on the end, the cable runs down the back of the rear board, just out of shot.
Ooh, have we got flashy lights? Yes, the LEDs show the activity on the pins, and the four along side the ports show when those ports have power.
All being well, the testing completes and all the devices pass the test. Any that don't (and it's very few these days), can be reworked and retested.
Might seem a lot of effort to go to, but we want all the products that go out to have been fully tested, so we can be sure if anyone has a problem, they need to clean their edge connector, or have a broken Spectrum, possibly a Z80 with a bad M1 line.
The DivMMC future is available to order now, to suit all sorts of Spectrums, even white ones. As a reward for reading this far, here's a discount code: TYNEMOUTHDIVFUTURE for anyone wanting to buy a DivMMC future. For those of you that don't want to buy one, here is a picture of a cat looking judgemental.
Thank you to Rod Hull at the Future was 8 bit for all the photographs used in this blog post (including the last one).

Sunday, 3 March 2019

LHT00SU1 Logic Analyser and Sigrok

As part of an upcoming blog post, I am going to need to include lots of oscilloscope screenshots, and I have been looking at this device as an alternative.
My previous efforts taking photos of the screen of my 30 year old 'scope have varied from OK to awful, and often took many goes to get a usable image.
I looked around at various options, but they were all a little pricey, and unless I suddenly get a rush of new Patreon supports, they are a bit out of my range. So I thought I would try the cheaper end of the market. I picked up this device, the LHT00SU1 for less than £25 delivered.
It has eight digital inputs, and two analogue, so would be ideal for the task in hand, which was looking at a composite video output and the digital signals that generate it. These are all connected via a 10x2 0.1" pin header.
The kit came with some cables and clips, although I'll probably not use there as they are a bit rubbish and holding onto chip legs.
I'll swap them for E-Z Hook probes I use elsewhere. I have found these to give a good connection and cope with a but of moving around without falling off, although a set of clips does cost more than the analyser itself.
The LHT00SU1 is available from a variety of sellers, described as "Virtual Oscilloscope Logic Analyzer". Based on all the listings I looked at, none of these come with software. It turns out to be  a clone of the USBee AX Pro, a discontinued product from a manufacturer that has since removed the software suite they used to supply. Presumably as a result of their device had been cloned. I'm not sure what all these sellers are expecting you to do, most of the descriptions talk about XP software, so I guess you need an old XP laptop and get the old software from
Looking inside, the heart of the unit is a Cypress FX2 chip (in this case, the CY7C68013A FX2LP). This is the sort of device where you plug it in and then firmware is downloaded to it and then it is detected as the end product. So without the original USBee firmware it's not much use.
A bit of googling comes up with Sigrok, the same open source software I use with my current logic analyser. That does support this hardware with fx2lafw, an open source firmware for these FX2 based logic analysers. This detects the device and allows you to select the firmware it uses.
With firmware on the device, it is detected by Sigrok as a CWAV USBee AX, with eight digital inputs and a single analogue input. It turns out the original device multiplexed with two inputs to a single ADC, the new firmware does support the switching, so you only get a single channel, but that's fine for my purposes.
I made up a set of test leads, including an analogue lead with a shielded cable and a phono plug on the end to pick up the composite video signal. I fitted a jumper on the second analogue input, to ground it, and somewhat shield the analogue input from the digital pins.
Time to hook this up to the device under test, one of my Minstrel ZX80 clones.
The E-Z Hooks are holding up well clipped to the chip legs.
I've entered a simple 10 PRINT program to fill the screen with X's so there is some data to examine.
Time to fire up the Pulseview program from the Sigrok suite. Good start, the device is recognised, and I've setup the channel names and run a capture.
That looks good, a whole screen's worth of video and the digital signals that built it up.
The analogue input has options so that it can be adjusted appropriately, here showing -1V to +3V to cover the range and that signal with space to spare. (although it's a bit annoying as this seems to get lost sometimes so you have to reset it)
Zooming in, it's less good. That was several horizontal lines making up a row of characters, and this is a single line.
It is clear from that screenshot that pulses are missing from the clock and load shift register signals. This would normally be cured by increasing the sample rate, and the device is meant to support up to 24MHz, but unfortunately whenever I select over 12MHz, the screen locks up when I click run.
So, I think this one goes down as a partial success. It's working, but not quite fast enough to show the information I need. Any suggestions for a device which will do the job?

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