You need a bigger what? Oh, a bigger DISK. - Torch Emulator Part 2

With the relative usefulness of the Torch Emulator (github page now available, more details below), I thought it would be a quick(!) diversion to have a go at compiling a program that would open a window in OpenTop. In the Torch documentation there is a programming manual which includes a simple c program that opens a window and shows the available ASCII character set. Not particularly flashy but it would at least prove how to open a window and link into it with other code. Nothing too earth shattering to be fair.

As there is no sign of this application on any disk I had to type it in myself which was (C)Not Fun. After correcting several typos that resulted in compile errors I reached a point I could not get past. The compiler was throwing an error that the file libw.a was of an unknown type. Hmm. This was a bit annoying.

Do you know the magic number?

It turns out that the 'magic number' is a Unix way of identifying the type of file, and it appears in the first few bytes of a file. Unfortunately, this file was saying it was type '000000' which the compiler/linker really did not like. This specific file, having the .a suffix, is actually an archive file. So I tried the Unix command 'ar -t libw.a' and it told me that the file was not a valid archive. Hmmm. 

Fortunately, I have access to several different disk images, including the original SysV floppy images. This gave me the chance to recover an earlier (or non-corrupted) version of the file. Or at least it would have if not for the support for the specific filesystems on the disks involved being removed from the kernel.

Tangent incoming.

I have a new laptop. It is the first new (personal) laptop I have had in twelve years. So I installed Pop OS on it for decent Linux Nvidia graphics support so I can play No Man's Sky. The latest version of Pop OS comes with v7 of the  kernel. Or 7.0.11 to be exact. The last version to support SysV filesystems was 6.14. Snap to me having to install a rather old kernel and then figure out how to get to the Pop OS boot menu. Fortunately, this wasn't too strenuous and didn't actually take too long given the power of my new laptop. Did I mention I have a new laptop? 😁

With my new (old) kernel installed, I could finally go and mount some disk images. I started with the Torch 'test system' disk image - available on bitsavers - but found that this did not actually contain the file. I assume because it's actually part of the development suite which includes the errr... includes which wouldn't be on a 'test' machine. So then I tried the other available image from bitsavers but this turned out to be exactly the same file I had in my image.

Finally, I turned to the SysV disk images I had. These are not formatted like normal floppy disks and this did cause some confusion to begin with. I had completely forgotten that these are archive disks (a lot of archive stuff in Unix isn't there?) and to access them required the use of the 'cpio' command. This command makes me shudder as I successfully destroyed my Linux Mint install on my old laptop a few months ago (not my new one - did I mention I have a new laptop?) by copying all the Unix files to their exact same locations in the Linux file structure. That was an unpleasant few hours sorting out that mess... So this time I made sure I was in a specific folder and used the command:

cpio -idmv --no-absolute-filenames < ../SysVDisk1.img

The important safety bit here was the '--no-absolute-filenames' which kept everything in the directory where we were located. Phew. And after about the third disk, I found the file I was looking for.

So with a new version of libw.a in hand would the code compile?

No.

I began to think that the version of libw.a on the Torch was actually not going to work at all. I had a look at the first few bytes of the libw.a file and a known good different file called libc.a. Very interesting was that the libc.a file had the following as the first few bytes:

21 3c 61 72 63 68 3e 0a

 !  <  a  r  c  h  > \n

But the newly copied libw.a file had:

0000 5757 726c 6173 2e6f 
      W W  r l  a s  . o

By now I was convinced that this file was not going to work. And it never would have. The file itself did contain the correct *.o files but they were referenced in a different way than the Torch was accepting. How this ended up like this I have no idea. But I needed that libw.a so I wrote a small python script to pull out the files to save them individually on a Linux machine (my new laptop - did I mention that?). Then I would copy them over to the Torch and re-insert them into a valid Torch archive file using the Torch terminal. Easy. 

(At this point I should say that this next section took me the best part of three days of spare time and a day of a weekend to sort out.)

Here's the handy python script I knocked up (or a screenshot of some of it anyway):

A professional developer I am not...

This successfully gave me the *.o files I needed which I duly copied over to the Torch. A quick 'ar r libw.a *.o' later and I would have a shiny new libw.a file. 

And did I have a nice shiny version of libw.a, ready to insert into my /lib directory?

No.

I got this instead:

No space? NO SPACE??

And so, finally, I get to the point of this blog entry. How do I make more room on the Torch emulators disks? 

The current layout of the disk is:

Partition 0    -    202Kb (that's KILOBYTES as in 1024 bytes multiplied by 202 - I'll die on this hill)

Partition 1    -    10Mb (/ i.e. boot partition)

Partition 2    -    5Mb (not really sure what this one is...)

Partition 3    -    26Mb (/usr)

Original disk image partitions

At the time (c.1985) this probably seemed to be an enormous amount of storage. But in 2026, this is far too small, especially since this disk image appears to not be a 'clean' install and with me adding loads of stuff to it. There is just no more room left. So, the question is, can I make the partitions bigger, say at least twice as big?

Possibly.

First things first. The emulator supports a single hard disk image. I need to update the emulator to support a second hard disk. This wasn't as hard as it might sound since it just required the addition of another copy of the existing hard disk code but tweaked to change the SCSI ID, along with a new command line option to mount it at startup.

Initially I went for SCSI ID 4 since this is way above the values of the original hardware. SCSI ID 0 LUN 0 is for the main hard disk with LUN 1 as the 'BlueSCSI' floppy drive and the Gotek is SCSI ID 1 LUN 1 so SCSI ID 4 seemed fair for a second hard disk image to keep it well away from any of the existing addresses.

Except, no. 

Caretaker actually seemed OK with SCSI ID 4. Unix, not so much. Because it's not a value expected by the Torch version of Unix I actually needed to create new nodes for SCSI ID 4. And this was a complete disaster. Whatever I did, any attempt to access the hard disk partitions through Unix resulted in a hard crash. After a few hours I gave up. So I went back and tried SCSI ID 1 with LUN 0 for the second image. 

And this just worked. More or less. I could run the emulator and enter the Caretaker disk manager program which appeared to give me to access SCSI ID 1. It also gave me a set of default values for the partitions on SCSI ID 1, except there was a problem. The 'size(K) left' value was -13000Kb. Ah. Well that's not right.  

Minus 13Mb? That's probably not correct...

After some head scratching I realised that if I turned off the 'partition alignment flag' for the partitions that had it set, then the disk space was shown correctly. So I left it switched off on those partitions.

Next problem. If I changed the size of the partitions that were not the last one then this would require the moving of some data (even though the image is technically empty). But this result in a crash 100% of the time when the partition information was written back to the drive. 

Crash! Ah-aaaa!

To get around this I had to set the partition sizes to zero. Then, as I added the new partitions with the increased sizes this meant that no data was 'moved' and the new partitions were just saved without issue. And these were the new sizes:

That's a bit more roomy...

So now the root partition has 20Mb and /usr now has 53Mb. But it's not done yet. This was just creating the partitions on a disk image attached to SCSI ID 1 LUN 0. I still have to create the filesystems and copy across the relevant system files.

I'm jumping ahead a little bit here, but for partition 0, this just requires the re-installation of Caretaker. This is simply an option in the main menu of the disk utility that automatically loads the required boot files onto partition 0. To make sure that there were no crashes, I reinstalled caretaker then immediately rebooted. This seemed to work and there were no error. Back to the regular bits of the disk...

In the Torch I needed to identify the correct device nodes in the /dev directory. Simply put, these nodes are the interface points for the hard disk. Fortunately, this was fairly straighforward. In /dev there is another directory called 'dsk'. Inside this are a series of existing nodes but the ones we're interested in are 1s0, 1s1, 1s2 and 1s3. The numbers correspond to the SCSI ID and the partition number. 

Interestingly, the 1s0 etc refer to SCSI ID 1 LUN 0 but the LUN is not included in the node, almost as if it is just implied. But it IS included for SCSI ID 1 LUN 1 as 11s0. Old computers are weird. Anyway, the final digit is definitely the partition number.

To make a filesystem, I executed the 'mkfs' command on each partition (substituting in the correct node and block amount):

    mkfs /dev/dsk/1s1 xxxxx (where xxxxx is the number of blocks required)

The upshot of all this is that the disk image should now be ready to receive files. To check I'd got this correct, I created directory part1, part2, part3 in the working Torch disk image. Then I mounted each part of the drive with:

    mount /dev/dsk/1s3 /mnt/part3 

And there were no complaints. This was a good sign as it suggested the filesystem had been mounted correctly. Even better was that I could write files to part1 and part3 and read them back, even after a reboot. I'm fairly sure that part2 is actually some sort of swap space (feel free to correct me in the comments).

With these all now in place, it was time to do what I'd been dreading. I needed to copy all the files over from each of the drives, starting with / and /usr. I had thought that this might be easier on Linux, but having mounted both image files, and after trying to copy the files across, it became very obvious that the modern Linux world does not enjoy trying to read and write ancient disk structures. So I went back to the Torch. 

And I should've done that first. It took less than ten minutes to copy the files across for both / and /usr and there were not complaints, no stumbles, no errors. So, the big question. Would the new image actually boot?

VICTORY!

And proof of the new sizes:

It's SO BIG!

That's 20Mb for / and 53Mb for /usr (I assume that partition 1 which is 8Mb is actually some sort of swap space).

And now I have the room, does my typed in program actually work now?

No.

I did get a new libw.a file that I had but despite it being so carefully crafted, it was missing its index. Whatever that means. It meant that the compile failed. Again. After all that work I was pretty despondent but then I did another 'ls' on the lib directory. Staring me in the face was a file called 'libW.a'. I began to wonder if this was actually what I needed so I went for broke and renamed it to 'libw.a' - Linux is case sensitive for filenames - and tried compiling again. 

Did it work?

Oh, yes. I had rather mixed emotions at this point. On the one hand I'd spent three days trying to get files out of an archive that the Torch apparently doesn't support (even though it's on the freakin' SysV disk) when I could have just renamed an existing file, but on the other hand, I've now got a big one. Disk image that is.

Ooo, he's a character.

Next time, time (you'll see).

If you'd like to follow - or even contribute to - this thing, see the github page at:

https://github.com/Crashedfiesta/torch-triple-x-emulator

Disk images are available from bitsavers:

https://bitsavers.trailing-edge.com/bits/Torch/

Caretaker may or may not be included somewhere or not in this thread (VCF forum membership required):

https://forum.vcfed.org/index.php?threads/torch-triple-x-c1985.1244837/

When is a Torch not a Torch? When it's an emulator....

The old hardware of the Torch Triple X is proving to be a little bit bothersome (it's a right old pain the rear) and I've made little progress in fixing the motherboard issues. I won't give up but it's taking longer than I ever thought it would.

It was making feel a bit despondent to be honest, but then, on the VCF forums, a most excellent chap disclosed that he'd written an emulator for the Torch, based on the Motorola 68000 emulator called Musashi. What. The. Heck. 

 

The first screenshot!

 

Holy [CENSORED]! Obviously I started to ask some questions. This first version apparently had some memory issues with the MMU, but what a start! 

Eventually these issues were resolved and the next screenshot provided was just stunning.

**Speechless**

This was running the regular hard disk image from bitsavers (on which my own physical Torch adventures are based!) and shows everything I would expect on the screen. Just. Wow. But then....

Networking. Oh. My. Goodness.

Needless to say, this was awesome work. But, you should know me by now. I wanted more. Fortunately, the working code was uploaded to the forums and the original author basically said 'knock yourself out' when I asked if I could start fiddling with it.

From this point on, I should point out that I am not proficient in 'C'. I know a reasonable amount of Python and I'm familiar with general programming principals (I am a child of the 8-bit era after all) but the C syntax is a bit odd to my Pythonic eyes, but not horrendously so. The main point I want to get across is that you are not going to see a 'tour de force' of programming skills and some things I do may make experienced guys out there cringe. I just want to make it work.  

First things first, the colours. I found the bit in the code that set the palette. It should be set from hardware (I think) but the code has fallback if the palette isn't set up. Since the initial version of the emulator was clearly using the fallback colours, it was a simple case of identifying the correct values for a more pleasing set of colours to replace the current pale blue/white palette. 

Colours. So many colours. Well, four anyway..

Normal(ish) colours for OpenTop

That made things look a bit more like home. :)

Nice.

 

It's worth noting that I spent quite a bit of time trying to make the emulator just use the colours that the system does without using the fallback colours. This proved to be far more difficult that I imagined. No matter what I tried, the palette will not use the 'real' Torch colours. I suspect that there is some hardware trickery going on on the real motherboard to make the colour updates as the Caretaker boots up. It's not a big thing since the colours I've put into the fallback do look quite reasonable but it is mildly annoying. 

Next thing, the aspect ratio. The display was squashed vertically and needed to be increased. Fortunately, this was a relatively simple tweak to the SDL window settings and then we were pixel perfect.

  

Running fullscreen on my laptop. Oh, yeah.

Next, the keydisk. This disk has a very annoying format that changes at the end and adds an extra track to extend the available space. This space stores the unit serial number and acts as the 'key' to unlocking the system. With the emulator set up as it was originally, the keydisk had to be present for every boot. This is not a major issue but it bugged me that it didn't try and store it somewhere so that if the keydisk wasn't specified in the startup parameters then it still startup correctly. Also, for the emulator, the keydisk image needs to be in .IMD format to ensure that the right part could be accessed for the serial number. But .IMD images can't be mounted on Torch Unix - something similar happens at startup in the 'real' hardware. The Gotek can read the .IMD image and boot the machine but then it cannot mount it in Unix once booted.

Looking at the code I could see that when the emulator reads the keydisk it takes the relevant piece of the special last track and copies it into the memory location of the real time clock. On the real Torch the RTC chip has a tiny amount of volatile RAM which is used to store this key number. By putting it there early on in the emulator startup, the WERMA startup programme (vaguely similar to a BIOS) doesn't complain when it compares the memory contents against the key disk. If it wasn't there then the message 'New battery fitted' would appear at every boot which would be a little bit annoying.

Anyway, rather than have the keydisk attached every time, I decided that when the Torch starts it will check for the keydisk number in a tiny binary file. If the number isn't there then it would carry on and do the 'copy and check' from the keydisk but would also create the tiny binary file 'torch_serial.bin'. Simple and effective. This also means that, in theory, the key disk image would not be required any more as the 'torch_serial.bin' file could be provided with the emulator. But that would be cheating. :)

 

I made this!

And it all works rather well.

 

Terminal output - found the keydisk and saved the serial number

After I'd done this I realised that, really, all I'd done was move the reading of the keydisk to a simple binary file but it feels easier not having to basically have the keydisk image there every time.  And if you really blur your eyes you can pretend that the 'torch_serial.bin' is actually stored in the RTC RAM. (You still need the keydisk to make networking work - but I'm getting ahead of myself.)

 

No need for the key disk on this boot. :)

 

Next up, I wanted to mount a regular floppy image in the emulator. This was partly the reason why I didn't want to have to include the key disk every time at startup, but in the end it turned out not to really make any difference.

Anyway, the Torch uses either the OMTI SCSI board to support both hard disks and floppy drives or a special 'MANTA' board to handle only floppy disks. For the purposes of the emulator, and trying to mount a Unix floppy specifically, we stuck with the OMTI configuration. This meant that the code for the floppy was basically a variation of the existing code to handle the actual SCSI hard disk. As such, it was reasonably straightforward to add another option (--unix-floppy) to point the emulator at a Unix floppy disk image. 

For the actual floppy images I initially struggled. But eventually I found that it was actually quite straightforward to create a blank floppy disk image like this..

In Linux, create a blank file of the correct size by running :

            dd if=/dev/zero of=floppyblank.img bs=1024 count=720

Then copy the image into the directory/folder with the Torch emulator. Include it in the startup parameters with:

            --unix-floppy floppyblank.img

Then, when the emulator has started, open the Torch terminal and su to be root. Then run the following:

            format /dev/fdsk/0

This is specific to the hard disk image I have so your mileage may vary if you use a different disk image. If so, just have a look in /dev/ and see what floppy disk devices might be there. Interestingly I struggled to use the /dev/floppy device which is also present, with Unix complaining "Can't determine controller type". But the /dev/fdsk/0 device returned no error on the format command.

Then, just make a filesystem on the newly formatted block device with:

            mkfs /dev/fdsk/0 1440

Finally, mount the image so it can be seen by the system and written to:

            mount /dev/fdsk/0 /mnt/flop

Obviously, my disk image has a directory called 'flop' in 'mnt'. Yours might be different.

The key concept here is that the filename for the disk image persists through the emulator session i.e. the image could be mounted in Torch Unix as described above, files written to it, unmounted in Torch Unix and then replaced with a different disk image PROVIDING it has the same filename. (It sounded a lot simpler in my head when I started writing that..)

To ensure correct operation of the floppy image, it's necessary to run 'sync' in 'tsh' and then 'umount /mnt/flop' which cleanly disconnects the disk image from the system and allows the copying of it to different locations.  

I did spend quite a lot of time trying to sort out why I couldn't have more than one floppy drive. The disk image I'm using has two nodes for SCSI floppy drives, /dev/fdsk/0 and /dev/fdsk/1. On the real hardware, the '0' was equivalent to the floppy image on the BlueSCSI and the '1' was the Gotek. But with the original code, whichever image I mounted appeared in both. It turned out that the original code was only considering the LUN for each SCSI ID. It was a simple(!) matter of looking at the whole byte of information relating to the SCSI ID. So we ended up with the following mapping:

        SCSI ID 0 - LUN 0 -> Hard disk

        SCSI ID 0 - LUN 2 -> Floppy drive (unix) equivalent to BlueSCSI floppy image

        SCSI ID 1 - LUN 2 -> Floppy drive (unix/keydisk) equivalent to Gotek floppy image

So mounting /dev/fdsk/0 now always mounts the image specified in --unix-floppy while mounting /dev/fdsk/1 mounts the image specified in --keydisk. For ease, I'll probably stick to just using the /dev/fdsk/0 node unless I need to copy files from one floppy to another.

That's 'proper' floppy disks sorted. Next thing. The terminal.

The terminal program on Torch Unix is 'sh'. Not 'bash' or 'csh' or anything modern like that. No siree. This is 1980s style computing i.e. a bit hard and slightly inconvenient. And the 'sh' terminal is just that. I realise it does come from c.1984 but having been using bash for the last twenty years or so, taking a step backwards is a step too far. If that makes sense...

Anyway, a couple of things that are missing from 'sh' are very annoying. These are command history on the cursor keys and auto filename completion on tab. I'll be upfront, I did not manage to get the tab key working (yet). But read on for the command history.

Rather than try re-write and compile a stripped down 'bash' (or similar) I decided to try and do something else, which would be a bit simpler. I would write a wrapper that would pass commands to 'sh' but which would store previously entered text i.e. commands and paste that history into the command line when the up/down arrow keys are pressed.  

The code itself runs and calls 'sh'. It's only 229 lines long and, I have to be honest, I wrote it so long ago (with copious amounts of duck-duck-go searching, stack-exchange browsing and swearing at errors) that I don't remember how I worked out what the heck to do. Documentation appears to be a mythical thing to past me. Perhaps I would make a great agile developer after all.. 

When I compiled it I renamed it be called 'tsh' (Torch sh - see what I did there?). I added an icon to the desktop - a feat in itself with the OpenTop system - and I run that instead of the regular terminal icon. I haven't figured out how to swap the icon from the default 'tool' icon yet, but I will. 😁 And I can definitely tell you what this code does. 

In a nutshell, it adds a command history on the 'sh' terminal. It also allows for switching to root using the new command 'tsu' which redirects the 'su' command through 'tsh'. (You can use 'su' in the 'tsh' terminal if you really want to but it runs the command normally and the ability to press the up arrow for the last command is lost as the 'tsu' version runs through 'tsh'.) And it is surprising how just making that addition suddenly makes the Torch terminal infinitely more pleasant to use. 

 

The OpenDesk desktop with tsh running.

 

There are still limitations to it though. There are only 10 stored lines so if you want to go beyond that then you're out of luck. When a history line is displayed it can't be modified other than by deleting a portion of it from the end i.e. if the command was 'mv verylongfilename1.txt short1.txt' you can't use the left and right arrow keys to move through the text to change the first filename, you'd need to delete the second filename and keep deleting until you reached the character you wanted to change. This isn't really a major issue, and I as keep gushing about, just having the last command available by pressing the up arrow is a massive improvement.

Next thing, the bootup sequence. This is sort of related to the colour palette thing. What should happen when the system boots is that the screen is solid cyan for a few seconds during a memory check. Then it switches to dark blue with cyan text and the caretaker version is shown. Finally, the palette switches to the four regular colours of OpenTop. (There are normally another couple of colour switches during bootup but we'll ignore those for now.)

Before I got my hands on it, the emulator ran so quickly that all of these steps are effectively missed. Occasionally, the Torch logo might appear for a split second. This wouldn't be an issue but there are a couple of key things that happen during the boot. A 'Stop' icon appears. This is broadly similar to pressing 'F10' or 'Del' when a PC boots to interrupt it and allow some action to be taken, typically entering the BIOS settings. On the Torch, clicking the 'Stop' icon gives access to three main options:

 

Some interesting icon designs there..

• O/S allows the user to specify which kernel to boot, usually 'unix'
• Key allows the user to open the key disk and access more utilities
• Go allows the use to continue the boot process

Clicking on 'KEY' gives these even more interesting icons:

Icons. Icons. Icons.

The most important utility here is the 'Disk Toolkit'. It allows for the partitioning of hard disks as well as given more information on the installed drives (or drive images in this case). It works as-is which is something of a miracle in itself. The only thing is that moving the mouse causes all sorts of random garbage to appear in the utility's command line. No mouse here so the SDL support does cause a minor foible. Don't touch that mouse!

 

Disc utility startup screen

 

Partition information 

(note garbage at the option cursor from the mouse!)

 

To keep booting, it's just a case of pressing the floppy disk 'boot' icon. 

One last thing. What time is it? 😁

Given that the emulator runs on a host of some description, it made sense to try and set the clock based on the what time the host says it is. There is one major problem with this. Although the time and date aren't an issue, the Torch OS is not Win2K compliant. As a result, it does not know any year past 1999. As a compromise, we take the time then the date (including year) and simply subtract 28 years so that the days are correct. For this emulator, this is OK.

And it works. Sort of...

 

Code snippet for clock sync from host OS

 

Firstly, the timekeeping is a bit erratic to say the least. I haven't got the clicks quite tuned in correctly just yet so the clock runs fast from the second the emulator boots.

Second, on Windows the time is correct, but on Linux, for some reason, the time is always one hour ahead. 

 

Time, time, time. It's actually 11:32pm. 😆

That'll do for now. (Is that not enough? Are you not entertained?)

Next time, if I can work out what the heck I'm doing, I set up a github page for this and try use git to maintain the code. It may not go well.... 

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