Clinging on like a Limpet (Board) - Torch Triple X Part 14

The Torch Triple X was working. Then it wasn't. Then it was. Then it wasn't again. 

I've been having some issues with the Torch. This has been a persistent problem for a little while (Future Paul here - looking back it's been an intermittent issue for two years or so!!) and I'm not really sure why. Every so often there is no boot and I get left staring at a pale blue screen. 

Sometimes it gets a bit further and I end up at the dark blue screen with 'CARETAKER1.3' at the top but then it stops with an error trap.

Trap.

Another, older trap.

Sometimes it will get to the Torch logo and I get an error trap. 

Well that's not right...

Sometimes it will start to load OpenTop and then freeze.

Don't panic! Too late..

You get the picture. Reliability is (R)Not Good.

I put this down to the Limpet board. This has been a thorn in the side ever since I managed to break off one of the pins on one of the stupid connectors it uses. I repaired it but that was, I think, the start of all the issues. I have tried multiple things since then to improve the connectors. I've replace the sockets for both of them on the motherboard, I've installed a totally different connector type, I've used multiple turned pin sockets stacked to act as a more stable riser etc etc.

Original Limpet board.

Stupid riser connectors..

After looking at the issue I decided to do something drastic. The original Limpet board is in a bit of a sorry state having had RAM sockets installed, then removed, then re-installed (all to try and solve this bloody fault) so I thought, why not just make a new Limpet board? It's double sided, relatively small and relatively (!) simple. Surely this is the sort of thing one of the PCB manufacturers could make?

Many, many trace repairs...

So that's what I did.

First, I had to create a schematic for the Limpet in Kicad. I have used it before to recreate the schematics of the Torch itself but when I did those I was a bit ham-fisted with the symbols and I wasn't too bothered about getting everything nice and resolved for PCB manufacture. 

I had to do it properly this time.

Fortunately, the majority of what I needed to do was fairly standard and I was already au-fait with a lot of the functions in Ki-cad. All of the chips were standard and in the regular library of symbols, except for the RAM. I had to take a previously defined chip and change it into one of the 'ancient' 505256 DRAM chips. This was a bit finnicky but once I'd done it, it worked - which is a good job as the RAM accounts for most chips on this thing!

Actually creating the schematic took a lot of hours. The first bit was fairly straightforward. Plonk all the components  on to the Ki-cad sheet and put then roughly were they are on the board. Then I took the original board and removed all of the components on it so I could see all the traces.  I was left with the bare PCB. I did notice that once all the components were removed the board has a massive bend in it. This could be why it was, or appeared to be, so unreliable.. With the bare PCB I could visually follow the tracks across the board and use my multimeter ('..in continuity." - StezStix) to verify I'd followed it correctly. 

Then it was a simple case of joining up the pins from the various components as per the tracks on the old board. This resulted in a slightly untidy schematic. After many hours of tweaking and fiddling it finally started to look reasonable. 

Pah. Simple.

I should note that this board also had four bodge wires on it that came from the factory which I also had to take into account when creating the schematic. This was fine for adding to the schematic, but it did raise one question. Should I try and 100% recreate the board as it was, or should I just do it to get a working board? Hmmm. 

Anyway, with the schematic now done it was time to start work on the PCB. This was also relatively straightforward. When you switch to PCB mode from the schematic, Ki-cad automatically dumps all of the components onto the board with all the pins linked as per the schematic but only conceptually. The fun part of this was starting to actually route traces between the components.

To start this I drew out the boundary of the board so that I could then approximately place the components where they would need to go. Then, before I even started drawing in the traces, I measured as closely as I could the positions of the connectors. These are key because there is a limited footprint for the board to fit, and all the connectors had to be in the right place or they wouldn't all er... connect.

All present and (more or less) correct.

So, finally, I managed to start routing the traces. And this took a LOT of hours. The DRAM bit was fairly easy as a lot of the pins connected through to the equivalent pins on chips further up or down the board. There were some very tricky bits too, partly due to space constraints but there was also one instance around the Limpet's LED, where my brain just wouldn't brain properly and it took me far longer than I care to recall to get the tracks correct.. 

And then, once I had done one side full of tracks, I got to flip the view and do the same again for the other side. By this point I had also decided I just wanted a working board, so I incorporated the four bodge wires into the design.

Finally, after nearly two weeks worth of spare time, I had a finished schematic and PCB layout. I printed it out at 100% scale so I could compare it to the original Limpet board. And realised one of the connectors was in the wrong place. Gah!

Top and bottom layers switched on.
Routing is fun...

And, of course, moving the connector altered a lot of the previously carefully routed traces.. Double Gah!

Take 2. This time, the connectors were all aligned with the original board. Phew!

Next step. Pick a PCB manufacturer. I went for JLCPCB as they actually seemed to be significantly cheaper (cheapskate) and had fewer issues with customs charges etc.

Their website was pretty good and considering I was a complete beginner at this I found it pretty straightforward to use. I had exported my design as 'gerber' files as exported from Ki-cad and I uploaded these to the website. A price was given - minimum order quantity of 5 boards - and then the files started processing to check for any 'gotchas'. 

Back Side Gerber

Font Side Gerber

After a few minutes the site came back with some potential pitfalls e.g. pads very close to tracks that could merge during manufacture. None of these looked significant (foreshadowing) so I accepted them and continued to the next step. Confirming the order and paying. I went for the regular shipping since this was only £8 or so. Word on the internet was that this would also avoid potentially overzealous charges from other 'carriers'...

Then it was just a case of sitting back and waiting. I ordered them on 18th May and they arrived on 29th May. So only 11 days, all the way from Singapore. Nice.

New boards left and middle, original right.

The quality of these new boards is astonishing for the price. I paid $8.90 for the five boards and $12.77 in shipping and customs charges making a total of $21.67 which ended up being £16. That's just over £3 per board. I could not even begin to buy the stuff I might need to make a board the old fashioned way for that price. Amazing.

But the big question is, would it work? Before I even started putting components on I did a quick check between ground and Vcc. And guess what. There was a short. A full on, 100% straight short between gnd and Vcc. What. The. Heck.

Well, you remember that warning that JLCPCBs website had highlighted about tracks being very close to pads? Yep. That's exactly what it was. For capacitor C45, the ground track was supposed to go to the first leg of the cap and then bend around underneath the cap and carry on its merry way. Unfortunately, it was too close to the other pad of the cap and so was attached to both sides of the same cap. Worse, the other side of the board at that point had Vcc, hence the short.

A quick 'update' with a craft knife removed the link. (I ended up soldering the required cap directly to the bottom of the board rather than risk trying to use the now sliced pad.)

Minor engineering fix...

Now it was time to install the components. I had bought some new capacitors and some new sockets to fit to the shiny new board. I did re-use a few original components i.e. the two tantalum caps but only because I didn't have any, and the LED as it looked a better quality than the ones I had.. 

Line 'em up.

Socket to 'em.

Lookin' good.

Several more hours involving a soldering iron later, I had the answer as to whether it would work.

No.

Darnit.

Break out the oscilloscope.

I started by focussing on all the links between the RAM. First up the RAS and CAS lines. These all showed a nice and strong repeating pulse, exactly as would be expected. All of the data lines also checked out, or at least they were all at the same value but not really showing any activity. Then I went to the write enable pins.

Oh. 

Bugger.

They were different across the columns of RAM chips but they should all be linked together. What has happened here? I'll tell you what happened. I forgot to add a PCB track to each of the rows of RAM that connected the /WE signals together and that also connected them to the rest of the board. 

DOH.

Fortunately, a simple bodge wire fixed this and gave me the chance to use my recently purchased solder mask and UV light kit to glue it down. You'll also notice from the picture that there are a few capacitors soldered to the bottom. There were only supposed to be two which, as per the original board, were not included. On the original these had been soldered across the legs of the chips on the top (very neatly) but since I added sockets I put them on the bottom (not quite so neatly). It makes no difference really but makes it easier to swap chips quickly.

Ooop, Another engineering fix...

Does it work now?

No. I just get the pale blue screen. Darnit (again).

But after a bit of fettling I managed to get to the dark blue caretaker screen. And then it kept going! All the way to the 'insert key disk' screen - which was because I'd forgotten to plug the SCSI cable back in. 

I did this but when I re-started it, it got stuck at the pale blue screen again. Hmm. Some more fiddling and try again. And this time it got to the Torch logo and crashed. By this point I had realised that there was something wedged under the board, and given the weird nature of the faults both now and previously, I began to wonder..is there some sort of mechanical fault causing the problems?

I wedged a red handled tool under the right hand side of the board and placed a weight on it (my old HP laptop). Then I turned it on. And it booted past the pale blue screen. And it booted past the dark blue screen. And it booted past the torch logo and the box telling me I'd fitted a new battery. In fact, it booted all the way up to the point where it complains about not being shutdown properly (the more things change the more they stay the same..). I carefully maneuvered the mouse and clicked 'X' to clear the window. 

And it kept booting all the way to OpenTop. Yay!

Most importantly, this confirmed two things. First, and most important, the Limpet board recreation works perfectly. Second, and far more problematic, this confirmed that the issues I have been having are almost certainly on the motherboard. *Activate Conflicting Feelings*

A bend in the road...
(I can't look at this any more!)

So, now what?

Well, the issue is clearly mechanical. This must mean that a connection or connections i.e. a trace or plated through hole(s) are broken but are re-connecting when the board has that worrying bend applied.

But the question remains, now what?

At this point, if this was an Amiga A500 or C64 I'd be looking for a different motherboard i.e. just replace it. The broken board would then become a parts board for stripping components for future repairs. But this is just not feasible with the Torch. I know only one other person with a Torch Triple X (excluding any museums out there). They're not exactly what you'd call common.

The options I have are:

1. Do nothing. It was a good run. I managed to get it to work but just call it a day.
2. Find where the breaks are and try and fix them.

Of course, it's option 2 all the way. :)

More next time!

Coming up....

Stop breaking down already! *Sheesh.*

After the debacle with the full height MFM hard disk and the exploding power supply (see here), I decided to come at the Cifer from the other end. In other words, I decided to see if I could use the BlueSCSI v2 to create a hard disk for the Cifer, even if that meant only using CP/M rather than the version of Unix that is hiding on the physical unit.

Working Cifer following PSU repair.
Yay!

There are a few obstacles to overcome with this. Firstly, the IEEE bus seems determined to just not work. It's almost as if the cable is not even connected to anything (foreshadowing)... I have had the bus responding to stuff previously, but it only ever seemed to work if the winchester disk boards were disconnected but the 68k auxiliary processor board left in.

But a quick test showed that, as it stood, the IEEE488 bus remained resolutely dead, no matter what boards were or weren't connected. Darnit.

I decided to trace the cables and make sure that there were no issues. To cut a very long diagnostic activity short, guess what? The IEEE488 cable that should've been connected to the disk processor board, wasn't. Doh.

After re-connecting it and trying again, the bus showed the first signs of life i.e. on startup, I could request it try to boot from a winchester disc (w10 through w17 although I think only w10 and w11 are actually implemented). It wouldn't find a drive though, but it was a start.

So, next I considered if the Xebec 1410 controller was faulty. This is required for the MFM drives since they have no real control electronics installed. I removed it and put a blank HD00.img file on to my BlueSCSI v2 and connected that up instead of the controller. The IEEE488 expects a SASI drive but given that SASI was the pre-cursor to SCSI they are fairly compatible (I hope).

And now when I select 'w10' there is a brief flash on the BlueSCSI. But the system hangs and requires a hard restart. Not great, but a tiny step forward.

Next thing is to try and accurately create a blank disk image that is already formatted for this particular version of CP/M. This absolutely requires an OS that can do useful things rather than the AI laden, advert infested thing that corporations insist on using, so I headed over to my Linux install. Creating a blank image is fairly simple with the command:

dd if=/dev/zero of=blankdisk.img bs=512 count=40960

This creates a blank 20Mb image. But that's just a series of zeros in a file and the Cifer expects to find a formatted disk filesystem. 

So then I did a bit more research and discovered the cpmtools package in Linux. This handy set of stuff lets you format a blank file into a blank filesystem for CP/M using any one of the many, many (many) formats. Then, once it's formatted you can even copy files to it and list those files in the filesystem. 

All this is great stuff and I created a couple of filesystems to try on the Cifer and see if I could get any different results out of the IEEE488 bus. And it was during the testing of these filesystems that disaster struck. Again. AARGHHH!

You have GOT to be kidding me.

This happened during one of the boots I did. One second the display was fine, the next it wasn't. What. The. Heck.

My first thing was to remove all the other boards other than the main processor board. Out came the 68k auxiliary processor, graphics board, IEEE488 SASI adaptor and the disc processor boards. This leaves the Cifer is about as bare a state as can be while still be usable, albeit a bit crippled without any disk capability. This would also show if the fault was on one of the other boards. Alas, there was no difference so the fault was definitely on the processor board. Double darnit.

Next, I thought that this could be a RAM problem. There are 8no 4164 DRAMs on the board. But they all checked out OK with my DRAM tester. There are also five static RAM chips on the board too. I didn't have any way to test these but I swapped them around and looked to see if the fault changed in any way. It didn't. Triple darnit.

Out came the schematics. Looking at the general arrangement of the chips I made a short list of the chips that I thought might be causing the issues. This list was constructed by looking at the data and control lines around the display circuitry and looking for anything that might cause problems if it failed. The list included a pair of 74LS244s, a pair of 74LS374s, a trio of 74LS158s, a 74LS32 at location ML94 and an 74LS04 at location M72.

I had a couple of options to test the chips. Or at least I thought I did. I bought a cheap chip tester a while ago but it has several limitations - mostly that it doesn't actually support that many chips. Of the batch I wanted to check it would only test the 158s, the 04 and the 32. So I brought out the big guns. I have an EEPROM programmer unit, model number T48. The software for this also has a very handy 'logic chip test' function which DOES support everything I need.

Logic test to the rescue!

Unfortunately, none of my selected targets proved to be faulty. Now, if you've seen any pictures of the processor board (one might appear below), then you'll know that they have a lot of chips. No fancy ULAs in this machine, oh no. Proper old school logic in this machine through and through. But most importantly, everything is in a socket (phew!).

Processor Board - lots'o'chips

So, I removed the board completely from the machine leaving it empty of PCBs and I took it to a safe location and removed and tested every logic chip, starting at one side and working my way methodically towards the other. 

No boards in 'ere mate.

And guess what I found... 

A faulty 74S32 - a quad, 2 input OR gate. It was at position ML71 which is (as you might expect) right next to ML72 which was one of my original targets, specifically the 74LS04 at ML72. Three of the OR gates in the 74S32 were permanently set high.

I did a bit of hunting through the schematics and found three locations where the chip was used. It looks like it handles memory size (2kb or 4kb), along with specific signals /BNK and FLASH. Given that the display has a number of lines that are rhythmically flashing, this could be a good sign that replacing this chip might solve the problem. Also, there's a CLK signal going through it too.

Memory control

Flash! A-aaa!

Tick-tock. I spy a clock (signal)

The faulty chip is actually a 74S32 rather than 74LS32. In general it means that the chip is quicker handling the signals. In reality, I don't think there's anything that critical for timing in this machine so I can probably get away with a 74LS32. I don't actually have any in stock, but as luck would have it, there are several scattered across the other boards, so I pinched one from the 68000 auxiliary processor board.

After a bit of a to-do getting the board re-installed (there's more cables than you think and they need to be in the correct order) I was ready for the switch-on....

Yay! It's alive (again)!

So, another repair. I need to order some 74LS32 and 74S32 chips so I can replace the one I pinched and have some spares. But at least it still lives.

Now, if it could please stop dying on me that would be great, thanks.

POP goes the ...

 ...47 ohm 3 amp current inrush device

A short post today. 

So, I had a major Code Brown moment with the Cifer. I have been trying to get the massive hard disks to give up their secrets to a BlueSCSI v2 but with little success. I've had great support from the creator but I have a sneaking suspicion that the Xebec controller board I'm using may be faulty.

Anyway, a couple of nights ago I tried again with the 10Mb Rodime unit that I have. No joy with initiator mode. I wondered if the drive itself might be the problem so I dug out the other unit. This one is a 20Mb monster but it makes enough noise to wake the dead when it's spinning up. The first video I took of switching on the Cifer, you can actually see me backing away from it as the howling starts...

To power the unit I'd been using the Cifer's power supply. A simple molex to the drive, then the regular  power connector to the IEEE488 HD board and a passthrough molex to the Xebec controller itself. Finally, another molex connector with an adaptor down to the correct connector for a floppy drive to power the BlueSCSI.

Preparing for action - those drive units are 
huge and inextricably heavy..

In this config, the Cifer still comes on but no peripherals are connected to the data buses. The IEEE488 card is just a power pass through and all other connections are direct to the power supply itself.

After carefully checking all the power connections and the config of the BlueSCSI I switched the power on. As expected, the Cifer's screen came on and the drive started to spin up. It got about a third of the way to the regular banshee scream but then faltered for a split second...

BANG!

The Cifer's screen went off, there was a massive blue flash from somewhere near the power supply followed by a cloud of magic smoke. I let out a whimper and punched the switch to 'off' at the power socket.

While checking myself for burn marks I realised that I hadn't tripped any circuits on my electrical panel (the lights in the work area were still on) and nothing was actually on fire. Phew!

But the smell of magic smoke was strong. What. Have. I. Done. 

There was nothing else for it but to dismantle the unit and get the power supply out again. And it didn't take long to find the issue.

Holy thermistor Batman!

Now call me old fashioned, but I don't think any component should have a hole in it accompanied by a grey smear on the nearby components. This is what you call a (magic) smoking gun. The component itself is a 47 ohm, 3 amp rated inrush thermistor - well it was before my hard disk decided to draw enough current to blow it to kingdom come. (The big resistor was already marked like that following a previous Rifa incident..)

It's a cheap and easy to obtain component, and two should be winging their way to me in the next few days. My hope is that if the hard disk drew enough current to cause a failure like that then it will have done its job and saved everything else. Fingers crossed...

I'm off to get some new underwear.

Getting to the SCART of the matter - Torch Triple X Part 13

So, using the Torch in black and white has been OK, but it's annoying that I couldn't get the colour SCART to work. It's RGB after all, and just getting 'G' (actually grey) was a bit frustrating.

Fade to grey (fade to grey).

Well, it turns out that I am an idiot. Not the first time I've said that and it certainly won't be the last. In the last post I mentioned pin 16 on the SCART plug but then moved on to more important things. But the thing is that pin 16 determines what mode the TV should be in, and not in the 'switch to this mode and stay there' sort of thing, but more like, 'to stay in a particular mode, look at this pin'. In short, I should've applied a voltage to pin 16 to switch (and keep) the TV in RGB mode.

Doh.

Back to the drawing board. Fortunately, my existing contraption did not really require too much modification. I had to connect another voltage divider to get the 3.5v on pin 16 from the 5v USB connection, and then I needed a SCART connector. This time, I went for a new connector rather than trying to re-use a pre-made but recycled plug. I thought it would make it easier (it most certainly did). 

New cable New connector  And I definitely did not forget the screw on cap... After all that, I plugged in my shiny new SCART connector, inserted the USB plug into the back of the TV and then turned on the Torch.

And..

..black screen.

Fortunately, I was a bit of an idiot (again). I had left the TV in RGB(S-video) mode. So I switched back to bog standard RGB and would you believe:

Colours, so many colours...

Well. That's nice. Let's have a closer look at the palette options. Fortunately, the Torch gives us an application to pick some pre-defined palettes in OpenTop.

Standard. We can modify colours individually if we want.
Weird that there's a bigger blue bar...

It's bit, errr, blue. Not a fan.

Hmm. A bit yellow this one. But not awful.

Only a Dragon user could like this palette..

Overall, the TV picture is OK although there is some interference. I'm fairly sure that this was also present on the Torch's CRT monitor but as it's a lot smaller, it wasn't quite so obvious. Certainly, it's easy to tell when the Torch is carrying out its memory check due to the vertical lines pulsing across the pale blue start up screen on any display. In any case, the picture quality is good enough for day to day use on a fairly standard 21 inch LCD TV with SCART.

The picture is, annoyingly, slightly offset to the left. This is apparently a common issue with RGB signals and is attributed to the sync signal. A tiny delay needs to be added to shift the picture to the right. If I ever get any time I will investigate further, but for now, it'll do. 

Here's a couple more Torch Triple X apps (games actually) but in the standard palette - no green screen here. :)

Basic breakout

I think every computer I've ever owned (except the Cifer - but I've not looked through all its disks yet!) has had a version of breakout. Heck, the version I played on the ZX Spectrum was written in Basic! This version is also a bit sparse but its playable. The angle of the ball changes depending on where it hits the bat but most times, not quite in the way you'd expect. If you manage to clear a screen you have to catch the ball to complete the level too, rather than the last brick re-setting things. And when you do clear the screen the same bricks re-emerge but your bat has halved in size.

Tiler

I put this screenshot up before the game has mixed up the tile so you can see it's the Torch Triple X logo. Once you scramble it, it's almost impossible (almost) to solve because the resolution is quite low. The responsiveness of the 1980s mouse (or lack thereof) makes it a bit of a chore to play too as clicking the squares may take two or three clicks. But, again, it's alright for a built in freebie.

Adventure. Or Colossal Cave Adventure.

It's an adventure game. If you're a game historian it's THE adventure game. It's entertaining enough and the parser is OK, but it is text only so you need to run it in a terminal window (duh!). Bringing back those 1976 vibes..

And that's it. 

What sort of ending to this blog shall we have? An instant one.

Putting the SCART before the (composite) horse. Torch Triple X - Part 12

(Reposted)

One of the major issues of vintage/retro computing as a hobby is that a lot of our beloved equipment is just wearing out. When these machines were originally built I suspect that most people would not have expected them to still be in action some 30 or 40 years later, especially the great hulking CRT monitors that accompanied PCs and workstations. I say 'great hulking' but there were also some small and cute monitors out there, and one of those happens to be a Sony Trinitron based monitor used with the Torch Triple X (yes, I'm still banging on about the Torch).

 

It's a Torch Monitor - Sony Trinitron Tube

My example is still working fine although I have to run it at maximum brightness to see the image clearly. There's not really any 'bloom' that might appear in CRTs this age when I do this, but it is Trinitron (there's a great video on Trinitron and summary of its development here and here.). However, it does make me worry that if this monitor dies, I'll be left with no way to use the Torch. I do have a second compatible monitor which is actually bigger, but this one has, you might say, some issues.

 

First up, it's green. It's not supposed to be but some for reason it's forgotten about the RB bits of RGB. Second of all, it's been in the wars. I opened it up - I don't like opening CRTs - and found what can only be described as a 'bit of a scrape'. An entire corner of the PCB is missing and cables have been soldered in to try and fix the problem. 

 

 

Green. Yep, definitely green.

Still green...

How the heck did that happen!?

This may be a future project but, for now, I'm still worried about what I might do should the cute Torch monitor up and die on me.

Fortunately, the video output of the Torch is RGB. Yay! This means that I should be able to build a SCART cable for it without too many issues which means I should be able to use any SCART equipped TV with the Torch. Yay!

Torch Schematic Extract - Connector is 8 pin DIN

The SCART standard (also known as 'Peritel') originated in France and normally carries RGB signals along with video composite and audio. It can also carry luma/chroma signals too apparently. But that's not what we're concerned with here. The connectors are comically huge compared to current standards like HDMI, and the pins also seemed overly fragile given that they are flat and not rounded like you'd find in a DIN cable, but they were surprisingly robust. For some reason, the standard was hugely popular in Europe but not really anywhere else in the world..

 

 

SCART Type Connector - It's a bit bulky..

 

Anyway, of the 21 pins in the SCART standard connector we obviously need the red, green and blue to connect through from the Torch. We also need a ground which has to also link to the RGB ground pins on the SCART connector. That makes 7 pins in use. But we also need a composite 'sync' signal so that the TV will correctly display the frames of video. Without this, the display would be, at best, a rolling unreadable mess, or at worst, a black screen.

And that's a bit of a pain. You see the Torch doesn't output a composite sync signal. It actually outputs separate HSYNC (horizontal sync) and VSYNC (vertical sync) signals. One or other of these is not enough to correctly drive the SCART video. They need to be combined somehow..

This is an issue that has already been found by others on different systems. A chap called Chris had exactly the same problem with his Atari STE. He solved it by using a CD4077 integrated circuit with an XNOR logic gate to combine the HSYNC and VSYNC signals. His description is here. A lot of what I do is similar to what Chris does - up to a point.

My first problem is that I didn't have any CD4077 ICs. The main purpose of this chip is to provide the XNOR logic gate. I am lazy and impatient (and cheap) so I didn't want to have to order any CD4077s. But, as luck would have it, I did have several CD4011s which have four NAND gates. And, as we all know, what can make an XNOR gate? Anyone? Anyone? Bueller? Bueller?

That's right. As we all know very well, an XNOR gate can be made via the use of five NAND gates. Yay!

To accomplish this actually requires the use of two CD4011 integrated circuits. As mentioned, each chip has four NAND gates so, obviously, it needs two chips to use five gates. These need to be connected like this:

Professional and high quality diagram...

Composite signal emerges from pin 3 of IC2. 

Next problem. The chips need 5v to run but the Torch doesn't output any voltage on the video port. Fortunately, most TVs these days have at least one USB port on the back, so as a quick and dirty hack I decided to use an old USB cable to drive the chips. This would be connected to the prototype board I would be using for the chips, and putting it at the TV end of the cable would allow me to plug it into the TV USB port. This isn't ideal, but for now, it will do.

Now to the SCART connector. After digging through my box-o-bits I found an old connector from a previous project. It's not great as it was from a commercial (if somewhat cheap) cable and so the pins aren't really intended to be re-used with new wires. But it was still possible to solder wires to them so I went ahead and connected up extension wires from each of the RGB pins, the main ground pin and the composite input pin. This would make it easier to alter the connections if I needed to (Future me:- "It didn't."). I also linked the RGB ground and composite ground to the main ground pin with some of the coated fine copper wire I have.

 

 

I don't think I'll win any beauty awards..

 

All set. And....

Nothing. No signal at all. Just a resolutely black screen on the test TV. Darnit.

I did some more reading and checked that output signal from my CD4011s looked correct (it did). But then I noticed something. The peak to peak voltages of the RGB signals were only a few hundred millivolts. The csync signal I was pumping into the TV was nearly 5 volts. The SCART spec says that the RGB signals should be a maximum of 0.7v and the composite signal around 1 volt. Ooops.

To get down to this I added a voltage divider using a couple of resistors so that csync signal would be a slightly more sensible 1v.

And....

...nothing. Still a black screen.

I did wonder if I needed to apply some voltage to the 'Blanking Signal' on pin 16 but it appears that this is only required if you want the TV to switch to the SCART input automatically so I didn't change anything there.

I went back and checked the signal from the CD4011s and it looked good, correct amplitude and definitely looked like the expected csync signal. Very strange.

With limited time to work on this I started to wonder if I could just generate a composite signal but that's not really that easy when trying to combine the RGB signals. But Amstrad did it with the CPC. Except their composite was monochrome. Hmmm.

So, for now, I have abandoned the SCART plug. I took the csync signal and added another small resistor, then I took the green signal and added the same value resistor as on the csync. Then I joined them together to make a monochrome composite signal.

 

 

Now with phono plug! 

And...

..it works! The picture quality is TERRIBLE but that's more likely down to the rather 'heath-robinson' construction of the circuit. There's wires crossing all over the place and it's probably a small miracle it does anything. There's interference every time it does anything, and the picture is offset to the left, enough to chop off a bit of the screen, but not enough to make it unusable. Fortunately, for my purposes, the offset picture in black and white is more than enough to use the Torch and explore it more fully. 

It works! And it's terrible!

These pics really don't show how bad it is...

But at least it's usable!

The added advantage is that, following careful negotiations, Mrs Crashed has permitted the Torch to enter the dwelling area of Crashed Towers. That means I can play with the hard disk and floppy images without freezing my backside off in the unheated workshop area* (*workshop are may consist of a corner of the garage). And having a bigger display for this makes it much easier too, so expect a long winded, nerdy deep dive into UNIX SysV, specifically the Torch XXX version. 

But why did the SCART cable not work? I'm not sure to be honest. I have a suspicion, now that I've had time to do a bit more digging (i.e. reading the wikipedia article properly), that I needed to connect some voltage to pin 16. Without this, the TV would assume that any signal coming in would be composite and not RGB which would, I think, lead to the black screen I was seeing. 

When I get a bit more time (Ha! Good one!), I'll revisit the SCART cable and have another go so we can get the colour output working properly. If I'm feeling flush I might even order some CD4077s to simplify the circuit. But I am cheap. :)