• Please review our updated Terms and Rules here

Torch Triple X c1985.

Annoyingly, I've got closeup pics of everything APART from the OMTI board. Guess that's a job for later then.
 
Witchy said:
Annoyingly, I've got closeup pics of everything APART from the OMTI board. Guess that's a job for later then.
Click to expand...
😁
I thought I'd cracked it last night as I started to fiddle with the jumpers on the OMTI. I set the floppy to be LUN0 and, when I started it up the floppy drive started to spin. Sadly, it didn't try and load anything and it eventually ended up at the key disk animation.

I also tried setting the 'ready signal' jumper so the drive always reports as ready but that just meant the thing got to the key disk animation quicker.

I've ordered some new chips to see if it that'll help. I don't normally like throwing parts at projects but I'm stumped (and annoyed it's so close) so I've ordered a couple of floppy controller chips (D765s) and a Z8 microcontroller along with a few logic chips. We'll see how that goes...

And one last thing, I also tried Caretaker 1.2 but it made no difference.
 
I received the floppy drive controller chips but made no difference, the controller makes no attempt to access the floppy drive. I've got the other bits arriving in a few days (Z8 and an assortment of the logic chips). If nothing in that delivery works on the OMTI, I'll have to resort to patiently working out signals with the el-cheapo logic analyser.

Of course, there could still be an issue on the main board. But then why would the SCSI drives still work? :confused:
 
Can you post your key disk floppy image? I'm curious to see what's actually on there.

I'm also trying to work up some motivation to emulate the OMTI specific SCSI commands. At the moment it just sends commands &C0 Define Flexible Disk Format and &C2 Assign Disk Parameters, then no further communication
 
The .scp file for the key disk is too big to upload (even .zipped) but here's the IMD I generated from HxC floppy emulator. If I've read it all correctly, the majority of the disk is empty. I think that would make sense as it's primarily got the necessary 'code' for the serial number security and the disk manager program.

Right at the end there's a little easter egg presumably from the Torch developers..
 

Attachments

  • torch_KEY_DISK1_imd.zip
    59.1 KB · Views: 5
Still waiting for the chips to arrive but realised I have two Epson mechanisms for SD500 units.

So, a question. Would there be any difference in the heads on an Epson SD500 versus an SD560? Physically, both units look identical, down to the five tiny wires that connect to the ribbon cable to the top and bottom heads. I think that the 500 is SD and the 560 is DD but my understanding would be that the 'improvements' to the units would be down to the more complex electronics that control the drive and the actual heads themselves would be exactly the same. 🤔

To be honest, I'm going to swap the heads over anyway so I'll let you know if I'm right! 😁

1000008955.jpg1000008820.jpg
 
Crashedfiesta said:
The .scp file for the key disk is too big to upload (even .zipped) but here's the IMD I generated from HxC floppy emulator. If I've read it all correctly, the majority of the disk is empty. I think that would make sense as it's primarily got the necessary 'code' for the serial number security and the disk manager program.

Right at the end there's a little easter egg presumably from the Torch developers..
Click to expand...
Yeah, they're quite big. HFE would preserve more of the data if you have limited space. IMD usually gets most of the data but can't store some of the tricks used on copy-protected disks. Though looking at the flux plot, it doesn't seem to be. If you set the HXC software to "Dummy disk" in the drop-down in that window, it'll give you a better view.

For the SCP file and anything else Triple-X related you'd like to share that's too big for the forum - I'd suggest uploading it to www.archive.org.


Re the floppy drive, I've never seen an Epson 500/560 so I couldn't say -- but I'd say the easiest way to fix them will probably be to swap the boards.
If you remove the heads you'll need to do at least a Radial Alignment and Track Zero realignment. Ideally you need a CE ("cateye") alignment disk for that, but you can use a pre-formatted floppy disk. Preferably not an important one!

I'm scratching my head trying to think of how the Torch might detect the floppy disk - but if it'd help, I have a SCSI analyser which should be able to see what the Triple-X is asking it to do. If that'd help and you're at one of the UK retrocomputing events that's coming up, feel free to PM me and I'll see if I can bring it along.
 
Agh, I've just re-read what you wrote. There probably isn't much difference between SD and DD heads. Could be the SD ones were straddle erase and the DD ones might be tunnel erase, or vice versa. The giveaway there is they'll look different.

Mostly the differences will be electronic. Probably just different settings on the read channel (there's usually a filter between the head amplifier and the peak detector) to account for the higher data rates. That's why I said it's probably easier to just swap the boards and see what happens - assuming all the other connections are the same.
 
Well, I just threw caution to the wind and swapped the heads.. I thought I'd cracked it but there's something weird going on which I think means you were right and I need to do an alignment in the drive.

At least it definitely reads, even if the bottom head (again) isn't great. That could be the drive the disk was written on. I need to find an original disk from something!

The photo shows the best read I got from the old drive with 'new' heads. Annoyingly, it looks very similar to the read I got with the previous heads but I'm still hoping it's just down to alignment...PXL_20241008_204220261.jpg
 
Well, I've learnt a few things this evening about the floppy drives. First up, I'm an idiot. In the post above the pic shows side 0 of the disk working fine but side 1 being a bit iffy. For some inexplicable reason, my numpty brain convinced me that side 1 was the bottom side and that I should adjust the whole head assembly to get that working and then tweak the side 0 (the "top") once I'd got the "bottom" all green. Well, as I found out, side 0 is actually the bottom head so at the point above, all I needed to do was try tweaking the top head. But no. I now have almost solid red on both sides following my half baked calibration efforts, because I'm an idiot.

Next, the epson SD500 drive mechanisms in the huge double drive are the same as the SD560. But the stepper motors are not. I decided to swap the top control board to one of the SD500 drives which would solve the un-calibrated head issue. But it was not reliable to say the least and behaved erratically. Thinking it might be that the bottom board needs a re-cap (the original Torch unit certainly did), I decided to swap the bottom board too. The boards on the SD500 and SD560 are the same size, same shape, have the same mounting points and, right up to the point I had to plug the cables back in, I thought I'd cracked it. But then I realised that the connector from the stepper motor on the SD560 had four wires. The connector on the SD500 has five. Gah! Cue me undoing all the screws in the board (again) and remounting everything back on the original drive mechanism

I haven't really lost anything as I still have a non-functional drive from the Torch (but I'm now 99% sure it just needs time and effort on re-calibration) and an unusable double drive for my non-functional Epson PX-8. But not the most productive of evenings. :rolleyes:
 
OMTI update. The pic shows the chips I've either replaced (even if the original tested good) which are highlighted green, or which I've just tested because I don't have any to replace them with and these are highlighted yellow.

There's not many chips left on there - probably three driver chips which are fairly easy to get, a floppy controller chip (£26!! For one!!!), and then the specific OMTI chips i.e. unobtanium. I'm really not sure what to do now. I could get some of the remaining chips that are available, and it's always good to have stock of this type of chip, but I'm not convinced there are actually any faulty chips on here.
PXL_20241014_183540219~3.jpg
Does anyone have any ideas? Would it be worth trying to plug the board into something that has a SCSI interface? The only thing I think I have with SCSI is a massive HP workstation that needs an OS installing (another sidequest 🙄).
 
There's a DP8303 transceiver sat in the middle which looks like it could be involved in the data path to/from the floppy controller. The FDC9229 isn't really a floppy controller - it's the data separator for the read circuit. It won't really be doing anything unless the drive is spinning.

What do you have on the SCSI bus? Obviously there's the OMTI card, but do you have a BlueSCSI, RaSCSI or similar SCSI controller or a hard drive on there too? (I'm wondering if there's some kind of addressing conflict which is upsetting the Caretaker).

If this machine were on my desk, my next move would be to hook up a SCSI analyser and see what it's doing on the SCSI bus, and what it's asking the Omti to do.
I'd also want to check the keyboard interface and make sure the keyboard was actually working. If it wants to see, say, an "enter" key before reading the Key disc, and your keyboard doesn't work, then that'd be a very easy fix...
Failing that, I'd probably try to blag a 68010 debug probe or ICE, see what it was executing and work from there - but that might involve disassembling the Caretaker software.

I appreciate a SCSI analyser isn't a common thing to just have lying around - I have a CATC one which isn't hard to move around (it plugs into a laptop) so if you're reasonably local maybe we could meet up somewhere. Drop me a PM.
Also, if you'd like those floppy drives aligning - I have alignment disks and tools to align them...
 
As there seems to be no attempt to access the floppy drive at all how confident are we about the jumpers W5-W8 being configured correctly? I believe my emulation accesses the Winchester on LUN0 and the according to the manual the OMTI ships with floppy assigned to LUN2. The jumper allocations can be overridden with the ASSIGN DISK PARAMETERS command, which I don't yet implement but the command is being used so will see what parameters are being sent.
 
I agree that checking the jumpers would be a good call (SCSI analyser would also tell which LUNS were being accessed, on the off chance the manual is wrong). Though I've checked the photo above - and they look right going by the service manual.
Going by the OMTI manual it's set up for --
- W0: 0 shorted, ID=0
- W1: 2-3, parity disabled
- W3-4: 01 (W4 closed), 17x512 bytes per sector on Winchester disk
- W5-W8: 0010 (W7 closed), LUN0/1 are Winchester. LUN2 is floppy. LUN3 is Winchester (tape is not supported on the 5200)


I've been dredging through the service manual and came up with a few more things which might be worth checking. (service manual -> http://bitsavers.org/pdf/torch/triple_x/Torch_Triple_X_Service_Manual_1989_MMCC.pdf )

- Does the HD146818 RTC have power? (the Triple X service manual mentions it on pages 53 and 61(. From the schematics it looks like this is powered by the battery, or by the +5V rail via D1 if the battery isn't present.
- Looking at page 69 (5.3.3 new battery fitted) it seems like the BBRAM being inaccessible might prevent the keydisk process from running to completion.

- Is the keyboard OK?
- I can't tell what type of keyswitches that keyboard has - but are they known to work?
- Service manual page 103 gives a test process for the keyboard - plug it in without a mouse and see if the cursor moves around the screen.
- There's also a pretty ominous mention that "problems can occur because of wires breaking inside the mouse cable". The same might apply to the keyboard cable... probing the data pin at the motherboard might be a good idea.
- There's an even more ominous note about the 631W plugs for keyboard and mouse needing to be re-crimped... ugh!


The vibe I'm getting is it's either wanting the keydisk to be in the floppy drive when the machine is powered on, or it wants a key to be pressed before it checks the floppy drive and there's an issue with the keyboard. Dodgy keyswitches or a bad cable maybe?
 
philpem said:
I agree that checking the jumpers would be a good call (SCSI analyser would also tell which LUNS were being accessed, on the off chance the manual is wrong). Though I've checked the photo above - and they look right going by the service manual.
Going by the OMTI manual it's set up for --
- W0: 0 shorted, ID=0
- W1: 2-3, parity disabled
- W3-4: 01 (W4 closed), 17x512 bytes per sector on Winchester disk
- W5-W8: 0010 (W7 closed), LUN0/1 are Winchester. LUN2 is floppy. LUN3 is Winchester (tape is not supported on the 5200)
Click to expand...
So, the ID of the board is interesting. When I got the machine, the controller was actually set to ID1 with a separate hard disk configured to ID0. The machine had been partially dismantled by that point though by the previous owner for storage, but I've got no reason to think that the OMTI wouldn't have worked at ID1, as it also came with two other drives (one very dead and one that still works if it feels like it, which would have been connected to this board). BUT, if I set the ID of the board to '0' then I get the 'Trap 0x14, pc = 0x102162' error whether or not another drive is connected at ID0 that might clash. I don't get any error if the ID of the board is set to 1 or above.

For info, I'm using a BlueSCSI2 as ID 0 which works perfectly but is obviously independent of the OMTI controller.

Just had a thought. Would the OMTI board require a hard disk to be connected for the floppy elements to work? There are no other drives connected to the board so it is just the floppy at the moment.

philpem said:
I've been dredging through the service manual and came up with a few more things which might be worth checking. (service manual -> http://bitsavers.org/pdf/torch/triple_x/Torch_Triple_X_Service_Manual_1989_MMCC.pdf )

- Does the HD146818 RTC have power? (the Triple X service manual mentions it on pages 53 and 61(. From the schematics it looks like this is powered by the battery, or by the +5V rail via D1 if the battery isn't present.
- Looking at page 69 (5.3.3 new battery fitted) it seems like the BBRAM being inaccessible might prevent the keydisk process from running to completion.
Click to expand...
I can see the supply voltage (which still runs at a startlingly low 4.6v) at the power pin on the HD146818. I also ran through the process to reset the memory on the assumption that if the contents were corrupted then that might be stopping it from working at all.

philpem said:
- Is the keyboard OK?
- I can't tell what type of keyswitches that keyboard has - but are they known to work?
- Service manual page 103 gives a test process for the keyboard - plug it in without a mouse and see if the cursor moves around the screen.
- There's also a pretty ominous mention that "problems can occur because of wires breaking inside the mouse cable". The same might apply to the keyboard cable... probing the data pin at the motherboard might be a good idea.
- There's an even more ominous note about the 631W plugs for keyboard and mouse needing to be re-crimped... ugh!


The vibe I'm getting is it's either wanting the keydisk to be in the floppy drive when the machine is powered on, or it wants a key to be pressed before it checks the floppy drive and there's an issue with the keyboard. Dodgy keyswitches or a bad cable maybe?
Click to expand...
I've checked the keyboard (see here) and it looks OK. When the thing booted to the 'insert key disk' animation for the first time (and I picked myself up off the floor), I used the keys to move the cursor around the screen until I managed to find the mouse. The mouse also works without any problem on the screen with the disk animation.

I've also tried every combination of keypress and disk insertion imaginable. Key disk in, power on, wait for the insert key disk animation, press Enter, press ctrl + Enter etc etc.

Unfortunately I'm not that close to you (down in the West Mids near Worcester) otherwise I'd have been round for a crash course in SCSI protocol analysis! ;)

One thing I haven't tried is connecting up the 'almost' working hard disk to the OMTI and setting the OMTI to ID0. I think it has the same OS as the newer, working drive but it uses the 34 pin and 20 pin connectors that would require it being connected to the OMTI. I just need to find the cables!
 
The 'almost' working hard drive was co-operating tonight. With it plugged in, powered up and spinning, it made no difference. No sign of life from the floppy drive still. If I set the ID of the OMTI board to '0' I just get the 'Trap 0x14' message. And, to be honest, any combination of drives and jumpers gives the 'Trap 0x14' message whenever the board is set to SCSI ID0. I'm starting to wonder if that means something...

One tiny thing I spotted is that the floppy light flashes very briefly once every five seconds or so until the 'Insert the key disk' message appears.

I'm going to order a couple each of the easily available chips that I haven't replaced/tested. I can guarantee if I don't it will be down to one of them.

Other than that, I've got an eBay search set up for an OMTI controller and it's just going to have to sit there for now. I'm pretty exasperated with it at the minute to be fair. A short period away might spark new ideas.
 
What happens if you have the Key Disk inserted before the message appears? The floppy light blinking sounds like the Caretaker might be looking for the presence of a disc. (from hazy memory, some models of Amiga do this)

I'm not sure if blindly replacing components on the OMTI is the way to go - but without seeing what the Caretaker is doing, it's hard to say.

MAME has an internal debugger -- I wonder if it'd be possible to set a breakpoint on the fault address and see what the Caretaker is doing?
 
You must log in or register to reply here.
Back
Top