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. :)