• Please review our updated Terms and Rules here

Torch Triple X c1985.

Sorry for going quiet on this for a while - a family emergency has reduced my available free time and so I haven't time to do any more testing. However, I did wonder whether the Triple X is expecting to see an error from the BlueSCSI/OMTI board when it tries to send the floppy parameters command to the hard drive? I think BlueSCSI just ignores the command but this might not be what the Triple X is looking for. I can't really think of anything else that might be going wrong.
 
kokoboi said:
Looks like i miss the lance too 🤷🏻‍♂️
Click to expand...
Interesting that your board is an issue 2 and mine is an issue 4. It looks like there are some bodge wires near the SCSI connector and RAM that my later board doesn't have (which makes sense).

The LAN chips were an optional extra and I think I might have the original purchase receipt from the previous owner somewhere in the pile of papers I have!

Yours doesn't have the 'limpet' board for extra RAM. But that means you have IC169 whereas I have IC44 and IC43 on the limpet which plugs into the socket for IC169.

If you power it up, let us know how you get on!
 
What else could we try to get the Torch XXX up and running? :unsure: This is where we are:

Boots from a real hard disk, demands 'key disk' but floppy drive does not respond when disk inserted
Boots from a BlueSCSIv2 with hard disk image, demands 'key disk' but floppy drive does not respond when disk inserted
Boots from a BlueSCSIv2 with hard disk image, demands 'key disk' but Gotek drive with key disk image does not respond when image selected
Boots from a BlueSCSIv2 with hard disk image and floppy drive configured, demands 'key disk' as BlueSCSIv2 and/or Torch software does not recognise the BlueSCSIv2 floppy drive correctly


The operation of the system goes something like:

Power on
Service Processor executes SIMON and holds 68010 HALT - screen is pale blue
SIMON copies ERMA from caretake EPROM to video RAM
68010 HALT is released and executes ERMA
RAM gets tested
Bwooop! (same purpose as a Mac chime) - screen goes dark blue
Start to boot SCSI hard disk and load WERMA - screen goes grey
Check serial number in CMOS static RAM matches number on hard disk and demand key disk if they are different <-----here we get stuck


Things to try and do:

  • Replace the OMTI controller - but unless you're Adrian (from ADB) and stumble across one on the bottom of an MFM hard disk, these things are rocking horse poop
  • Work on the open source BlueSCSIv2 software and try to improve the floppy drive support - the most excellent Rob has had a bit of a look at this
  • Stop the Torch asking for the key disk in the first place - assume this would require disassembly of the Caretaker ROM to find ERMA and an understanding of where and how the machine is asking for the serial number (stored in the 146818 clock chip in the 50 byte user RAM) and if there's any encryption going on (unlikely given it was 1983?). My simple brain thinks it should be feasible to find the serial number check in the code and patch it so it just skips over the check but then I'm not a software developer.
  • Continue to turn the Torch on and off every now and again in the vain hope that the OMTI has healed itself or the BBRAM has suddenly remembered the serial number. 😟
 
I got Pernod's MAME implementation up and running on a Pi a few weeks ago in the hope it would help explain the interactions with the OMTI board. I made some progress but the use of the DMA controller and my rustiness with 68k assembly language hindered things.

It would be useful to run some tests on a working OMTI 5200 to see if/where it behaves differently to the BlueSCSI implementation. However, as you say, they aren't exactly common so getting hold of one isn't all that likely. I could try running some tests on my OMTI 20B board but I don't know how similar that is to the 5200. It definitely lacks the floppy hardware.

Another option would be to try to find a Manta board for the floppy and then use a straight SCSI connection for the hard drive. I remember reading that Jules Richardson had picked up a load of Manta boards years ago but haven't tried reaching out to see if any of them would be available.

On the key disk, I think Tony Duell posted that it's possible to get around the security so it may be worth reaching out to him as well.

(These are all from notes I made when I first got my Triple X board and did some googling - they were old posts then and even more time has passed since.)

I do need to get my PCB up and running - I need to make a video cable, PSU and connector and burn the Caretaker ROM. My board is also missing IC69 (presumably it had a limpet at some point) but I'm hoping that won't stop it booting.
 
Crashedfiesta said:
Check serial number in CMOS static RAM matches number on hard disk and demand key disk if they are different <-----here we get stuck
Click to expand...
This is really nagging at me ... I've seen CMOS RAM chip failures in other machines (it's a common failure item on the Acorn 32bit machines)... it's also a piece of core hardware which isn't likely to be tested in a selftest (except maybe that the clock is incrementing) because it contains configuration data you wouldn't want to have corrupted.

Now what happens if you can write to it but it always reads back as garbage? Maybe the TripleX boot code notices and resets it - but the chip returns garbage, so the next bit of code which assumes the CMOS contents are sensible goes pop. Indexing a jump-table out of range or storing a pointer in CMOS could cause the boot process to crash.

So I would add another step on before you start poking at the Omti and going down rabbit holes: make sure the chip selects to the 146818 are okay, check it has power (with machine on and off) and check it's doing sensible things. If you can't test it, I think the same chip is used in the BBC Master. It looks like Mark Haysman at Retroclinic has some for sale for about £7 - https://www.ebay.co.uk/itm/266986745836

Honestly for £7 and an IC socket - if I couldn't test it, I'd just swapt it to rule it out, and put the original back if the fault symptoms didn't change.

And it'll be easier to find than a Manta board... Jules might be a tricky route, as I understand it most of his collection is in storage in one country while he lives in another. Never hurts to ask though, he might know someone else who has one to sell.
I sadly don't have a current email address for Tony Duell, we last exchanged emails some time ago while he was on his p850ug1 Demon email address. I do hope he's still around - he is, as the saying goes, a scholar and a gentleman.
 
philpem said:
So I would add another step on before you start poking at the Omti and going down rabbit holes: make sure the chip selects to the 146818 are okay, check it has power (with machine on and off) and check it's doing sensible things. If you can't test it, I think the same chip is used in the BBC Master. It looks like Mark Haysman at Retroclinic has some for sale for about £7 - https://www.ebay.co.uk/itm/266986745836

Honestly for £7 and an IC socket - if I couldn't test it, I'd just swapt it to rule it out, and put the original back if the fault symptoms didn't change.

And it'll be easier to find than a Manta board... Jules might be a tricky route, as I understand it most of his collection is in storage in one country while he lives in another. Never hurts to ask though, he might know someone else who has one to sell.
I sadly don't have a current email address for Tony Duell, we last exchanged emails some time ago while he was on his p850ug1 Demon email address. I do hope he's still around - he is, as the saying goes, a scholar and a gentleman.
Click to expand...

The HD146818 is already socketed. ;) Once I get out to the workshop I shall double check that it looks like it's doing things. One thing that may be relevant is that, just before I first got it to boot to the dark blue 'Caretaker 1.3' screen I had followed the procedure to reset the CMOS RAM as I was wondering if it might be corrupt. It could just be coincidence that it then booted as I think I also replaced the Limpet board at the same time (@RobColeman I think if you don't have IC69 you might not get it to boot - I will double check!).

Also, bear in mind that there is no battery currently connected to the CMOS so it is effectively 'off' as soon as I turn off the main power supply. This (I assume) means that every time it starts it will ask for the key disk as it will have lost the data in the RAM - although as I reset it, it's not going to have the correct information in anyway. I may have to look to hook up a battery and diode arrangement to keep it powered and see if that impacts anything. And, like you say, seven quid for a spare 146818 is pretty reasonable so I may just get one as a spare anyway.

I did find the posts from Tony and Jules but as they were from so long ago I wasn't sure if they were still active.
 
Crashedfiesta said:
Also, bear in mind that there is no battery currently connected to the CMOS so it is effectively 'off' as soon as I turn off the main power supply. This (I assume) means that every time it starts it will ask for the key disk as it will have lost the data in the RAM - although as I reset it, it's not going to have the correct information in anyway. I may have to look to hook up a battery and diode arrangement to keep it powered and see if that impacts anything. And, like you say, seven quid for a spare 146818 is pretty reasonable so I may just get one as a spare anyway.
Click to expand...
That might be contributing, and I'd fix it as soon as you can. You may not need a battery - if you've modified an ATX power supply then you could use the 5V Standby supply to run the RTC in place of a battery. That'll stay up as long as the PSU is plugged into the mains, but the main 5V/12V etc. will only be there when PS_ON is grounded (you could put a switch on it if you haven't already).

Otherwise three AA alkaline batteries in a battery holder and a diode to stop the Triple X from trying to charge them is what I'd likely go with.
 
Crashedfiesta said:
What else could we try to get the Torch XXX up and running? :unsure: This is where we are:

Boots from a real hard disk, demands 'key disk' but floppy drive does not respond when disk inserted
Boots from a BlueSCSIv2 with hard disk image, demands 'key disk' but floppy drive does not respond when disk inserted
Boots from a BlueSCSIv2 with hard disk image, demands 'key disk' but Gotek drive with key disk image does not respond when image selected
Boots from a BlueSCSIv2 with hard disk image and floppy drive configured, demands 'key disk' as BlueSCSIv2 and/or Torch software does not recognise the BlueSCSIv2 floppy drive correctly


The operation of the system goes something like:

Power on
Service Processor executes SIMON and holds 68010 HALT - screen is pale blue
SIMON copies ERMA from caretake EPROM to video RAM
68010 HALT is released and executes ERMA
RAM gets tested
Bwooop! (same purpose as a Mac chime) - screen goes dark blue
Start to boot SCSI hard disk and load WERMA - screen goes grey
Check serial number in CMOS static RAM matches number on hard disk and demand key disk if they are different <-----here we get stuck


Things to try and do:

  • Replace the OMTI controller - but unless you're Adrian (from ADB) and stumble across one on the bottom of an MFM hard disk, these things are rocking horse poop
  • Work on the open source BlueSCSIv2 software and try to improve the floppy drive support - the most excellent Rob has had a bit of a look at this
  • Stop the Torch asking for the key disk in the first place - assume this would require disassembly of the Caretaker ROM to find ERMA and an understanding of where and how the machine is asking for the serial number (stored in the 146818 clock chip in the 50 byte user RAM) and if there's any encryption going on (unlikely given it was 1983?). My simple brain thinks it should be feasible to find the serial number check in the code and patch it so it just skips over the check but then I'm not a software developer.
  • Continue to turn the Torch on and off every now and again in the vain hope that the OMTI has healed itself or the BBRAM has suddenly remembered the serial number. 😟
Click to expand...
The machine I have came with few floppies. May be one of them is the key disk, and my disk dump is already on bitsavers: https://bitsavers.org/bits/Torch/Torch_Triple-X_SysV_Portable_Disk.img.gz
 
RobColeman said:
I do need to get my PCB up and running - I need to make a video cable, PSU and connector and burn the Caretaker ROM. My board is also missing IC69 (presumably it had a limpet at some point) but I'm hoping that won't stop it booting.
Click to expand...
I have a horrible feeling that without IC169, it won't boot at all. I need to 100% confirm by removing my Limpet but I never got the thing to start without the Limpet installed but that could be because once it started to work (following my improvements to the power cabling) it had the Limpet already installed and I've not removed it since. But looking at the schematic it does look like IC169 is 100% to do with the VME interface to the Limpet only.

1746042604124.png

So for IC169 the /OE is held low anyway, pins 2, 5, 7, 8, 9, 12, 13, 16, 18 and 19 go the VME interface, and pins 14 and 4 head toward bus control for the VME, so it looks to me like the only pin that could stop things working is 15 /BERR. I'm no hardware engineer but I wonder if you held the '/BERR' signal high i.e. false, then it might work since, to my simple brain, that seems to be the only line that could impact the operation of the system. :unsure:

Any hardware chaps who are currently hyperventilating, please feel free to comment. :LOL:
 
Many thanks for this and it makes sense to me. I wonder how difficult it would be to try to recover the PAL's equations? I think the 16L8 means it's combinational rather than registered so possibly easier to figure out?
 
RobColeman said:
Many thanks for this and it makes sense to me. I wonder how difficult it would be to try to recover the PAL's equations? I think the 16L8 means it's combinational rather than registered so possibly easier to figure out?
Click to expand...
If it's not had the security fuse blown then it can just be read out. If it has, I have a DuPAL which can run the PAL through all possible input states (and for Registered PALs, all possible register states) and figure out the logic. The output is a set of equations which can be turned into CUPL files and from there compiled for a new GAL or PAL. They may not be identical to the original programming, but they'll be logically equivalent (PALs are an AND-OR array so with OR not being order-sensitive, there will be eight logically-equivalent programmings for each output pin).
 
Ha! I was just reading a very interesting document on PAL chips on a website called philpem.me.uk 😁 😋 (I understand about 10% of it so far! 🧐🤔)
 
Crashedfiesta said:
Ha! I was just reading a very interesting document on PAL chips on a website called philpem.me.uk 😁 😋 (I understand about 10% of it so far! 🧐🤔)
Click to expand...
If that's on the PE2BZ or Electrickery subdomains, that's a mirror of someone else's websites :D
I don't think I've written a page on my own about them, unless it's part of another project.
 
@RobColeman sadly, I can't get my board to boot without the Limpet board plugged in. I'll double check and see if there are any jumpers that are telling the board it has extra RAM but I think that without IC169 it won't work. 🙁

I tried just removing the Limpet which effectively removes IC169 and IC132. It didn't boot (not surprised on that one!).

Then, I removed IC132 from the Limpet and put it directly in the socket and tried to boot but with no luck. I just get the 68010 timing out error beeps.

So then I tried tying pin 15 of IC169 socket to Vcc and, to be honest, there's a flash of picture distortion that looks similar to the Limpet board RAM check. But no boot.

Then I tried tying pin 16 of IC169 socket to Vcc but just got the same. And also got the same trying to tie pin 3 to Vcc.

So then I went for broke and tied pin 3, 15 and 16 to Vcc but no luck. It refuses to boot without the Limpet. With the Limpet reinstalled it boots fine. 🙁

And, of course, I suspect none of us have actually got IC169 as we've all got or had a Limpet at some point. Darnit.
 
That's a shame but thanks for testing it. I did a bit of reading up on the VME bus signals and had a look at the schematics yesterday. I think the equations for IC69 should be fairly easy to recover if only we had a working example!
 
RobColeman said:
That's a shame but thanks for testing it. I did a bit of reading up on the VME bus signals and had a look at the schematics yesterday. I think the equations for IC69 should be fairly easy to recover if only we had a working example!
Click to expand...
@kokoboi has IC169. :) I can see in the motherboard pic that was posted and I commented on it too.
 
You must log in or register to reply here.
Back
Top