Torch Triple X - Part 11 - The Highs and Lows (and Highs) of Retro Computing

Last time I managed to get the Torch Triple X system to boot an image that did not require the key disk. Yay! The only problem is that, although Unix starts and I can log in to it and run things, there isn't a proper GUI running. It's just a terminal window.

But there was another disk image available on Bitsavers that had been dumped from another machine and I started to wonder if there was any way to get this other one to boot on my Torch.

I hatched a cunning plan. What if I copied the image on to my BlueSCSI but called it HD50.hda which would make it SCSI ID 5 alongside the working boot image? Then, I could mount that in the Torch disk tool and have a closer look at it. And I did. And it worked perfectly. Although there was nothing interesting in the partition information (it looked almost the same as the other image), I decided to try the 'Reinstall Caretaker' option on it. This, in my simple brain, would re-install caretaker as per my version of the ROM and include - if I'm lucky - my keydisk information. Then, assuming it all worked, all I would need to do is get the keydisk working again and it should boot on my machine. 

Well, the reinstall caretaker option didn't generate any errors so I assumed it worked OK. (Note from future me - I'm not sure this step was necessary as I had another go later and as long as the keydisk image was in the Gotek it just worked.)

Next was making sure I was using the right keydisk image on the Gotek. The keydisk is a primitive (and somewhat annoying) method of ensuring that the Torch is using an authorised version of its ROM and system. If the system loses its settings because of a failed battery (for example) then the key disk is required before the system will boot again.

I've captured images of the keydisk for my machine using the most excellent Greaseweazle from Kier Fraser. Several different images in fact, to make sure I don't lose this vital part of the computer and the image that actually works is already firmly ensconced on my Gotek. So, after renaming the hard disk image to HD00.hda I started to boot. 

And, oh. My. Goodness. It booted. But not only did it boot, this image actually has a working GUI which is known as OpenTop. 

It's a GUI. Crikey!

And it booted straight into it with no login required (phew!). Now that was unexpected.

We'll come back to the software because between the last post about the Torch and this one, I've also been busy with a few hardware bits and bobs.

First, the key disk. Clearly I've got the key disk working but one of the problems is that because I'm not using the original power supply which had a battery on it (grrrr!), every time I turn the Torch off the information about the key disk is lost and it needs to reload it again. This isn't that much of an issue, but it could become annoying when I finally work out how to access the floppy drive within the OS as I currently have the Gotek with a USB stick and the key disk is the image that is always currently selected. 

So I decided to fit a battery to make sure that the battery backed up RAM keeps its settings. This requires putting a voltage across the correct lines on the power supply connector that would be there all the time the machine is off. And the easiest way to do this is with three 'AA' batteries that provide 4.5v (ish). This is just enough to keep the BBRAM happy and I just so happened to have a battery holder that would do the job. The only issue with this is that when the Torch is switched on, it will try and charge the batteries which, for non-rechargeable batteries, is a one way ticket to magic smoke (or worse). This is the same issue when any of my Amiga using readers would have replaced an A500+ battery with a button cell. The simple answer is a diode in series which will stop the charging from happening. 

Now, those of you familiar with electronics will know that to push electrons through a diode means that you get a little bit of a voltage drop, typically 0.6v. This puts the output of my batteries at 3.9v. There are two reasons why I'm OK with this. Firstly, it works. Second, when AA batteries are new they tend to put out a little bit more than 1.5v, sometimes as high as 1.7v. Now 1.7 x 4 = 6.8v. Minus the 0.6 for the diode and you get 6.2v which is worryingly high for what I want it to do. So, using only three AAs means a maximum of circa 5.1v which becomes 4.5v after the diode. Obviously, this goes down to around 3.9v if the AAs are spitting out a more realistic 1.5v but, even at that low value, it's enough to drive the few bytes of RAM in the relevant chip when the machine is off. (Anyone who disagrees - let me know in the comments.)

3D printed battery as I only had a four cell
holder!

Another use for solder braid. The 3D printed
battery needs a pass through or no circuit!

The holder has a standard connector (like
a 9v battery) for easy removal. Yay!

With that sorted, I wondered if I could make the changing of hard disk images a bit easier. I had already had a go at designing a custom bracket for the Gotek (and I was very pleased with the results) but I started to think I could add a slot for the SD card used by the BlueSCSI. My first idea was to mount the BlueSCSI above the Gotek but it got really complicated to work out if I could support both in an open box shape but while still allowing enough room to squeeze the Gotek in. 

Hmmm. What else? If only I could extend the SD card slot on the BlueSCSI so it sat above the Gotek but still keep the BlueSCSI mounted where the hard disk had been originally. And, of course, there are plenty of SD card extenders on the market so I acquired a couple to see how they would work. One thing I found immediately is that if you try using one in a laptop, it does not work correctly. This seems to be because the laptop finds something plugged into the slot i.e. the extender bit, but then when putting the SD card in the other end it can't automatically detect anything has happened. 

Fortunately, the BlueSCSI will only have the SD card removed while the machine is off and then reinserted before switch-on. Provided an SD card is there at switch-on, it works fine, even on my Linux laptop.

After a couple of days of adding to the bracket design - which consisted of several test prints of the new section to check the fit, I was ready to try a full print. And I just went for it and did it on the highest quality. About 18 hours later I had a new bracket, ready for the SD card extender. While I was at it I also created a bracket for the BlueSCSI. Once I work out how to do it, I will probably upload these to Thingiverse (for the worlds smallest audience!).

Test prints - small sections made things a lot quicker
to print and try out, especially the SD card fit.

Only 18 hours to go...

I replaced the previous bracket and the new one looks AWESOME! The first font I picked in TinkerCAD (where I did the 3D modelling) was a match for the actual Torch Computers font too. I added a last minute mod by drilling a hole next to the slot and fitted a 2.5mm red LED which connects back to the BlueSCSI so you can see hard disk access too. Yay!

Not the greatest picture but SD card at the top,
Gotek USB stick and OLED screen underneath.

Gotek and SD card bracket to the right, BlueSCSI bracket
to the left. Note the SD card extension cable.

By this point I was ready to get the whole thing buttoned back up, or at least put the top back on and make it look a bit nicer. And this is where things started to go a bit wrong...

First, the power cables are all scrunched up in the back as they come off the motherboard and disk devices and are fed through the slot where the original power cables would have been plugged in. With my arrangement there are many smaller cables to squeeze through, making it difficult to get the centre and top sections of the case on properly.

While poking and prodding something, unbeknown to me, had gone wrong. After booting a couple of times it went into low resolution rather than the normal high resolution. Hmmm. More poking and prodding. And then, disaster.

It refused to boot. On closer examination I could see that LED on the Limpet board was only flashing four times instead of the regular eight. This, I think, means that the RAM test on startup is failing. Removing and re-inserting the board made no difference. This was Not Good (R).

After all of the wins that lead to the triumphal boot into OpenTop, it looked like I had basically broken it. And to say I was 'gutted' doesn't quite do the feeling justice. This thing is super rare and, as far as I know, there aren't really many that are actually working (batteries in power supplies etc). So to think that somehow I snatched defeat from the jaws of victory was beyond galling.

(Actual footage.)

Anyway, I decided to see if there was anything I could do to fix what seemed to be a broken Limpet board. I have to be clear that it's not just a case of removing the Limpet and running on 1Mb of RAM. The Limpet contains a couple of additional PAL chips that replace the original PAL chip that is removed and replaced by one of the Limpet connectors when it gets installed. And I don't have this original PAL chip so if I can't make the Limpet board work then it's game over. 

First, test the bus driver chips. These were fairly standard 74F245s ('F' meaning 'Fast' so the standard 'LS' won't do here). None of the chips on the board are socketed so they all had to be desoldered, sockets installed and then re-inserted. This also meant I had to remove the de-coupling capacitors that had been soldered directly to the power pins on the chips. As I was adding sockets, this meant putting them on the bottom of the board instead of the top but other than that, this was fairly straightforward. 

Socketing in progress..

Some new old stock 74F245s

Capacitors to the back, please..

Sadly, the driver chips were all OK (along with the support logic chips too). 

Then I decided to test all of the DRAM data, address and control lines to check if a trace had broken. But these all proved to be OK.

Next, I checked the actual DRAM chips. I wondered if one had completely failed resulting in any chips beyond it on the bus not being able to be seen. But again, they all came up as working correctly.

Finally, my great punt, I removed the two connectors that extend from the bottom of the board and which fit into two chip sockets (20 pin) on the main motherboard. I really hate this connection method as the pins were no thicker than standard turned pins but were much longer, and I had had issues with one pin on one of them before so I just decided to replace them. To do this, I got a big pack of turned pin, 20-pin IC sockets and stacked them together to the same height as the board required. Then on the underside of the Limpet, I soldered some turned pins I had leftover from a previous project. These fitted into the two sockets perfectly and, although the height was a fraction lower than the original connectors, everything seemed to fit together fine.

And the result was....

...still no boot. After many frustrating hours of fiddling, lifting, gently pressing chips, adjusting pins etc, still no boot. 

Then I got cross. Given that the issue arose while I was prodding stuff, I pressed the Limpet board down, hard (and I mean hard) and switched it on. 

And it booted. As if nothing bad had ever happened. Whhhaaatttt??

I'm still not 100% sure what had happened but I think it's fair to say that there was some 'mechanical' issue that my gentle caring hands were never going to fix. Brute strength and ignorance seems to have saved the day (this method is obviously NOT recommended).

And, not only did it boot, it now boots in the higher resolution and it has done ever since.

So after about four weeks of despair, I found myself back where I started, trying to get the Torch Triple X looking good. Here's the result.

This time, accompanied by Ziggy*

*When Ziggy has batteries, pressing his head results in him shouting 'Tickle!' at an excessive volume, followed by him moving around in circles in a very unnerving way. Ziggy does not currently have batteries.

Next time, we shall explore the OpenTop GUI (spoiler: it won't take long..).

Now I have an even older one - PET 4032

It was my birthday a little while ago. To celebrate, Mrs Crashed arranged for us to go to the National Museum of Computing at Bletchley Park. But not just to visit the awesome museum. The NMOC were actually holding their 'Retro Electro Jumble Sale' and I had to be there. 

The sale itself consisted of a large room with lots of glorious (but unwanted) retro computers in various states of repair on and underneath several tables. I hadn't really gone with the intention to get anything specific but after looking at a couple of Atari ST's (a bit too new) I was drawn to the PETs that had been strategically placed under the tables. Some had a their price tags marked as being reduced from £50 - a bargain in itself - to £30 but then realised the reduction was because the motherboards had been removed.

But then Mrs Crashed found one that had its motherboard and it all looked intact. We lifted it onto a handy trolley nearby and then checked the description and cost for this specific unit. Cost £50, condition - rusty. And it also had a label on saying 'Screen garbled. OK inside.'

 

I frequently feel the same...

This was the one for me. And I also managed to grab a period correct cassette drive too, price £3.

Presenting- Rusty!

After the discounts from our entry tickets I realised I had managed to bag a CBM PET from around 1979 for less than £50. It certainly didn't matter that it wasn't working as that was the point of buying it. A project for my birthday. 😁

And then the work started..

The PET is very easy to work on thanks to the ability to lift the top of the unit up and prop it open, just like a car bonnet. Nice. A quick inspection revealed that the inside while 'OK' was rather dirty (and not nice). I also spotted the infamous 'white' sockets in use on the DRAM, ROMs and the CPU which are well known to be a source of issues with this type of computer.

Open wide...

The power supply is the slightly terrifying arrangement of mahoosive transformer and giant green capacitor on the left. I don't know if there are any magic smoke bomb Rifa capacitors involved here. If so then they are well hidden. I decided to just go for it. First switch on attempt gave a screen full of garbage, as expected:

No surprises (sounds like a great title for a song..)

This is good as it shows that the CRT is OK - white which was a surprise, I was expecting green - and the video generation circuitry is working OK. The brightness control at the back of the CRT also worked as expected.

But then, within a couple of hours, the screen was black when I turned it on. Interesting. I went around the back and tweaked the brightness of the CRT to maximum and saw a single thing line across the centre of the screen. So that meant the vertical deflection had collapsed. Awesome. 

Fortunately, with the schematics available from zimmers.net I managed to track down the fault to a 74LS107 which feeds the 'vert_drive' signal. With a new chip in place, the screen was back to being garbled, but at least it was visible (IC death count : 1).

74LS107 at H8 was dead

One thing I should point out about this unit is that it is a 4032 i.e. a slightly newer model of PET with 32kb of RAM and, obviously, a much better keyboard. The motherboard matches the schematic of the 'dynamic' system board which means it's the second(ish) type of motherboard that Commodore came up with. It doesn't have a speaker so there is no sound at all on this PET, and it doesn't have the CRTC chip which means that this machine is strictly 40 columns only.

Checking out the rear..

Motherboard with ROMs & CPU removed
(and a little bit cleaner)

Anyway, while checking the various clock signals that should be on the board, I found a dodgy looking one from pin 13 of the 74LS164 at H3 on the board, and touching it with the scope probe filled the screen with the character 'h'. I had some 74LS164s so I replaced it and that restored the expected clock signal (IC death count : 2).

And then I realised that the CPU was not outputting anything from its own clock signals. The 6502 CPU has two clocks phi1 and phi2. After ordering a couple of replacements (you can never have too many chips) I started to wish that I didn't have to wait but I didn't have any machines with a 6502. Having been a speccy guy in the 80's, most things I had were Z80 based. But then I remembered I had been given an Acorn Electron a year or so ago. And sure enough, the 6502 in the Electron was socketed. Replacing the 6502 restored phi1 and phi2 to the expected signals (IC death count : 3).

Correct clock signal from the borrowed 6502. Yay!

This was all before I even posted on the VCF forums about the issues I had which should give an idea of the body count (of dead ICs) at the end of this project.

Anyway, by this point I now had the screen displaying this:

Still garbled but different..

Changing the CPU had changed the garbage on screen and the result was a little bit more like what would be expected at a normal PET cold start. What would normally happen is that there would be a blast of garbage on the screen followed by the screen clearing and being replaced with a basic prompt. This is obviously not happening yet.

I also managed to check the DRAM by the simple method of taking a ZX Spectrum, which uses the same DRAM for the lower RAM, and desoldering all its lower RAM, soldering in sockets and swapping the PET RAM into it, one bank at a time. It seemed a good idea when I started but at least the speccy now has sockets for the lower RAM.. No faulty chips were found but, unfortunately, I had an incident where I replaced one of the DRAM chips in the PET the wrong way around. This was 'Not Good' (R) and caused an immediate burny electronic smell. It also killed the chip. (IC death count : 4) Fortunately, I had another DRAM that was a larger memory size but could be modified to fit - which I did.

But still no change. The next thing to try was the video RAM. The guys on the VCF forums had indicated that the video RAM was an almost certain failure. The two MOS 2114 SRAMs are notorious for failing (as a lot of MOS chips are) so two more modern replacements were ordered. Then I ordered another pair, but a different manufacturer, just to be sure and have some spares. 

At this point I was introduced to the idea of using the PET Tester ROM by the most awesome Daver2 over at the VCF forums. This is a small program that sits on a 2716 EPROM and so it can be swapped with the edit ROM (which is also only 2kb). It runs a very simple program at start-up, first to test the low page memory before moving on to more advanced tests including video RAM and DRAM tests. I actually had to order a 2716 as the only one I had was as dead as a doornail and no amount of UV exposure in the phone sanitiser would cure it. (Not counted in the death total as it was already dead.)

When the new EPROM arrived, I copied the PET Test ROM to it and swapped out the edit ROM. I was disappointed to see no real change. After a few hours of poking I found a 74LS244 at position C3 with an address line stuck high. This meant that no code could properly run from the test ROM and so it needed replacement. Fortunately, this was one of the chips that I have plenty of so it was no big deal to replace, other than the slight hassle of de-soldering it from the board and installing a socket (IC death count : 5).

Still no joy, and the screen just kept displaying the same pattern of garbage on screen. But then one pair of the video RAM chips arrived and so I replaced the 2114s. 

2114s - they were not socketed originally

This was a partial success (IC death count : 7). The PET Test now started with its initial check - YAY! - but instead of progressing, it sat with only the first character on screen changing rapidly, as if it was cycling through a massive list of values - BOO!. This was not right and I wondered if this was still an issue with the video RAM since the test it got stuck on was the video RAM test. Basically, it writes certain values to the video RAM and then reads them back. If they all match then the test ROM moves to the next test. But as the chips were new it seemed odd that this would be the case.

First signs of life but stuck here...

While I was probing around I accidentally slipped and shorted a couple of data pins together and suddenly saw that the test ROM had moved on to the next tests. It ended up on the DRAM tests although there was an issue with the text. According to Dave I'd basically crashed the initial test and by some miracle the code in the ROM continued. It did allow me to quickly check the keyboard - a series of numbers are displayed by the test ROM which change when keys are pressed. From this I could see that only the 'W' was a bit iffy and this also meant that the 6520 controlling the keyboard was OK (foreshadowing...).

Tests working but only because I crashed the first test....

I've got how many 'k' of RAM?
Looks like I broke it...

It also allowed me to check that the ROMs were 'OK' via their checksums. I downloaded the equivalent ROMs and put the binary file into a hex editor and calculated the checksum of those and they all matched. Nice. Of course, it's not really easy to check the Edit ROM but I did put it in one of the two spare ROM slots and the reported checksum initially matched but it was not to last - but I'm getting ahead of myself.

So, if the first test isn't getting through, this suggested a problem with the video RAM (still). With no video RAM the PET should display a fine checkerboard pattern. Well, mine did but it wasn't exactly stable..

That's not really a checkerboard, is it?

I put a switch on IC F1 (74LS108) between pins 6 and 7 (the TV_SEL) line. This effectively isolated the bus from the display meaning that the we could (in theory) track down where the noise was coming from in the display. With the switch open there was what looked like a random pattern of characters spiralling up the screen but with it closed the display was rock solid. Then followed a few days of measuring lots of signals, with the switch on and with the switch off, find another signal, measure with switch on and with switch off etc. 

This is what it should look like with no video RAM!

During all this I replaced one of the 74LS157s which I think was the one at F3. Either way, the display suddenly became much more like the expected fine checkerboard pattern but it still wasn't stable. (IC death count : 8)

Better, but not quite there..

At some point I also replaced the 74LS373 at G3. (IC death count : 9).

And then, for no apparent reason, the display became rock solid with or without the switch closed. As Dave put it, there's a metal mouse loose somewhere... The only thing I can think is that in my handling and additional cleaning of different parts of the board had I removed something I wasn't aware of causing a possible short? Either that or the Retro Computing Gods decided to give me a break?

Whatever. The display was now working. I replaced the VRAM and turned it back on and, sure enough, the PET Test ROM ran exactly as expected. 

I decided to go for broke and put the Edit ROM back in and promptly found out that it had failed completely. (IC death count : 10). 

Hmm. That's still not quite right is it.. Dead ROM

So I reprogrammed the PET Test ROM to be the Edit ROM and reinstalled it. All I got was a black screen. Hmmm. I removed the 6522 but no change. So I removed the 6520 from C6 and I saw this...:

..And nearly fell of my chair. 

But all is not right. Where's the cursor? The 6520 at C7 should give the cursor but it's missing.

I thought that the sockets for the gaggle of 40 pin chips - including the 6520s - might be causing problems and confusing things, since tapping the top of the 6522 caused some garbage on the screen. Fortunately, I had quite a few dual wipe 40 pin sockets in the box o' bits' so that was no problem.

White sockets looking a bit bendy

White sockets begone!

And that did absolutely nothing except stop the garbage on screen when I tapped the 6522. From that I have to assume that one or more of those three chips is faulty. The chips in question are the two 6520 PIAs which control various input/output stuff such as the IEEE488 interface and the keyboard, and the 6522 VIA which controls various other input/output stuff including timers and IRQ things.

I decided to go all out again and just order replacements for all three. If I'd ordered just one 6520 (say) and then found out it was the 6522 I'd have had to order and wait again, so it made sense. They aren't that expensive and the 6520s have a modern equivalent of 6821. I actually ended up with a ceramic 6522, one 6520 and one 6821.

But while I was waiting I wondered if I could use a different EPROM in place of the Edit ROM as I only had one 2716 ROM and I didn't want to have to keep reprogramming it between PET Test and the Edit ROM. The thing is that the actual ROM is pin compatible with the 2716 but I only have 27c128 or 27c256 EPROMs to play with. The 2716 is 2kb while the 27c128 is 16kb and the 27c256 is 32kb. But that's not the biggest problem. The 27c128/256 have more pins than the 2716 and I can't just cut them off.

Typical 2716 EPROM
(This one is OKI and is also dead)

So I built an adaptor board instead. 😊

First attempt!

The adaptor basically swaps a couple of pins that are different between the 2716 and 27c128/256 and either puts the extra connections to ground or ties them to 5v depending on what they are.

I have to tell you now that the first version did not work. At all.

Fortunately, Dave on the VCF forums came to the rescue and told me that I'd connected pin 21 of the ROM socket, which is a permanent 5v, to pin 22 of the 27c256 which is /OE or 'Output Enable'. Since /OE is 'active low' me tying it to 5v very effectively disabled the chip since /OE would never go low. Doh!

A quick re-wire later, where I also found another non-working connection, and I was ready to try again. And this time, it worked! More or less..

Interestingly, the keyboard came up as all 'ff' instead of '00' with the 27c256. I'd copied the PET Test ROM across the chip 16 times to ensure that it was consistent, the original PET Test only being 2kb. I'm not sure whether there may still be a slightly 'off' connection somewhere that might cause this. It also seems to cause a weird issue when the RAM test runs through. But don't let that distract us, not just yet.

Because the postman had been! Yay! In the bags were the 6522 from Devon, and a 6520 and 6821 all the way from Germany (bizarrely cheaper and quicker than ordering from the UK). 

First up, put the 6520 into location C7. And we got...

...a working PET! With a flashing cursor and everything! There was still a slight glitch on the video but Dave confirmed that the 6522 handled a signal that, if not present, would cause that. So I inserted the ceramic 6522 and tried again. Same result but without the glitch. Nice! And finally, I added the 6821 into location C6 and tried again. Same result again. This is starting to look like a working PET! It also means that both original 6520s and the 6522 are dead. (IC death count : 13).

Some little BASIC bits and bobs:

HELLORLD! as made famous by Usagi Electric

Can't have a Commodore running without the random 
maze Basic program. :)

But is it really working 100%?

Not quite. If I want to add one of the modern SD card adaptors then I need the IEEE488 port to be working. There is a BASIC program that can be entered which works by poking values into certain locations, and then peeking at the values of nearby locations. The values in these second locations would show if the IEEE488 parts were working. And this was the result:

Darnit. Bits 0 to 3 and bit 7 are faulty.

That's annoying. There are three MC3446 chips that control all the IEEE488 comms and this shows that at least two are faulty. A very nice man on the VCF forums suggested a supplier for the chips that seemed to be a good bit cheaper than eBay so I gave them a go. And after a couple of days, two MC3446s popped through the door in a jiffy bag.

By this time I'd already put the three 3446 chips into sockets so it was a piece of cake to swap the old ones out and put the new ones in. (IC death count : 15) Looking at the schematic I worked out which pair were impacted and which one was still working and swapped them over. And the result was:

Yay! No more bit errors!
(or other errors!)

But what about the cassette deck, I hear you cry? Well, that just needed a new belt, only because the old one was stretched, and thankfully had not turned to goo.

Belt up young man!

I also cleaned the read and write heads along with the capstone and pinch-roller. And it just worked, 100%. I managed to type in the IEEE program and then save it back to a cassette tape multiple times. Very simple and easy. Nice!

One last thing to do (well two actually). Clean the hideous keyboard and clean the case. I won't actually do much more to the case than that to be fair. The rust is part of the computer's history and it's not actually that bad, certainly most rust spots appear to be surface only.

But the keyboard. Oh, my, goodness. The keyboard. It's easy enough to remove, just a bunch of screws and a connector for the cable. And it's a good job because it was filthy. Absolutely hideous.

Keyboard connector on the motherboard

Connector at the keyboard end

Filthy keyboard (oversized belly for scale)

Fully dismantled and ready for a bloom' good wash

Cleaning keyboards is not a fun task. It's easy to forget how many keys are on a keyboard, even one from 1979(ish) before the general layout we know today had become established. But it must be done!

Commence rebuild!

Rebuild complete - what a difference a couple of hours
of extreme cleaning, careful drying and reassembly makes

When I managed to test the keyboard previously the only key that seemed to give any grief was the 'W' key. So I paid special attention to the circuit board and plunger at this location. Once it was re-installed in the PET the 'W' worked perfectly. Nice.

Stand by for action!

I still need to clean the case properly but I won't be doing anything with the rust as such. It's part of the history of the machine and it adds a certain 'rustic' charm (try the fish, I'm here til Thursday!).

There you go. A Commodore PET for under £50 (plus about £25 quid in new parts). There were a total of 15 chips that had died in the PET, although I think that the 6520 in C7 was working originally but died at some point during the investigation and testing. Here's a picture of most of the dead ICs:

We salute our fallen heros.

If you want to see more of the technical help given to me by the VCF guys take a look at the thread here.

 

Torch Triple X - Part X (that's 10 in roman numerals you know.)

Before we start todays epic, well written and informative blog*, here's a quick video which I took a few days ago. 

*your mileage may vary

As you can see, not only does the Torch boot up but it can mount other disk partitions and, rather excellently, play games! This is eerily reminiscent of one of the first games I played on the ZX Spectrum way back in 1985 which was a simple bat & ball breakout style game which I think was written in Sinclair Basic. Anyway, I'm rubbish at games.

More interesting was that I could actually mount the other partitions on the disk through a bit of trial and error. The /dev folder contains a list of 'devices' that the disk image would have access to, but there are more there than are actually in use. To work out which ones are available was simple case of creating a folder in the 'root' folder and then attempt to mount each of the devices to that folder as a mountpoint. For example:

#mount /dev/disk0b /root/hd0

If the 'diskxx' was valid then there was no response in the terminal and I could go and 'ls' the hd0 folder. A lot of the diskxx came up as 'unable to mount diskxx' (or similar) which means that the device exists in the /dev folder but isn't actually related to any valid disk partition.

From all this I managed to mount (and then umount) all of valid partitions. There were two that seemed to just contain basic unix installs, but there were also two that, while similar, contained a 'games' folder, hence the video.

With all this I started to wonder if I could mount these disk images in a more modern unix like operating system i.e. Linux. This would make it much easier to read through the config files and potentially update them (**foreshadowing**) to get the system booting fully. But how do I do that?

To be honest, I had tried before with zero success. Every time I would try to mount the image I would just get a long winded error about 'incorrect fs, bad superblock blah blah I'm not doing it so nyar' or similar.

Anyway. I decided to try again but this time I did a bit of research. It soon transpired that I am an idiot. I should have realised that I could not just mount the whole disk image, rather I had to mount the partitions. But to do this, I need to know where the partitions start. And this is where the Torch disk utility comes in.

When the Torch boots there is an icon of a hand with the word 'STOP' underneath it. Clicking this during the boot process brings up a few more icons, one of which is the 'Disk Toolkit'. 

Torch menu - Boot, Disk Utility or Password?

"Here be dragons!"

After a friendly warning that you really need to read the flippin' manual and a couple more confirmation screens (which disk to select being the main one - default is SCSI 0 LUN 0 which is fine), a rather utilitarian menu appears.

"What option(s) do I have?"

From here I need option 5 - Partition hard disk. What this does is give lots of options of how to handle the existing partitions but more importantly, it tells me where on the disk the partitions are located. 

Location, location, location.

The photo above shows that this particular disk image has four partitions:

Partition 0 - size 247 kilobytes, start address 4

Partition 1 - size 10000 kilobytes, start address 498

Partition 2 - size 5153 kilobytes, start address 20498

Partition 3 - size 31500 kilobytes, start address 30804

To mount them in Linux is now fairly simple. Take the SD card with the image and plug it into a handy laptop running some version of Linux. Head to a terminal and type the following:

#> sudo mount -o ro,loop,noload,offset=2048 mydisk.img /mnt/mymountfolder

where 'mydisk.img' is the name of the disk image and /mnt/mymountfolder/ is the folder to mount the partition to.

The offset value is the most important parameter here. It tells the system where the start of the partition is. To calculate the offset, take the start address and multiply by the sector size which in this case is 512kb. So 4x512 makes 2048. 

If successful then there is no feedback from the mount command but the folder /mnt/mymountfolder will now contain the files on that partition.

A couple of caveats. More modern Linux versions may not have UFS active by default. I found I needed to start this on one of my Linux installs with 'modprobe ufs'. UFS is the legacy unix filesystem and, again, some modern linux systems i.e. the ones that try to be as user friendly as possible, may not support writing to UFS. I found my Mint install couldn't write but my ArchLinux laptop had no problems and didn't actually even need the modprobe.

It remains to be seen whether having read/write access to any of the disk images will end up being useful. I am hoping that I will be able to decipher the startup sequence on some of the other disk images and work out how to get the full GUI running.

Anyway, in other news I have managed to source a reasonably priced replacement IC for my OMTI controller card. It arrived all the way from Germany (thanks Deutsche post!). I'd previously worked out that it was this specific chip thanks to a quick chip swapping session with the working OMTI on loan from binarydinosaurs.co.uk and, as luck would have it, it was the second chip I swapped that proved to be the faulty one.

Please work, please work, please work....

After removing the offending faulty chip from my OMTI board I very carefully inserted the new (old) chip and pushed it home into the PLCC socket. This was rather more stressful than I had imagined as the socket was surprisingly tight. I took this as a good sign.

OMTI5200, now with new(old) chip.

But does it now work? After carefully dismantling all the cables around the 'on loan' board I even more carefully plugged it all back in. I also checked the SCSI ID was correct at ID 1 for the floppy. And then, I switched it all on...

Success!

Yay! It worked! I now have a fully working OMTI5200 board so I can finally return binary dinosaur's board. Wa-hoo!

Next time, some more disk image antics and I try working out how to access a floppy drive.