Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Yes, I think you're right. I had the HD image labelled HD10 but reading the manual I assume it should actually be HD00. I'll have another go tomorrow.
| VCF West | Aug 01 - 02 2025, | CHM, Mountain View, CA |
| VCF Midwest | Sep 13 - 14 2025, | Schaumburg, IL |
| VCF Montreal | Jan 24 - 25, 2026, | RMC Saint Jean, Montreal, Canada |
| VCF SoCal | Feb 14 - 15, 2026, | Hotel Fera, Orange CA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | June, 2026 | Atlanta, GA |
-
Please review our updated Terms and Rules here
Torch Triple X c1985.
- Thread starter Crashedfiesta
- Start date
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
@Pernod you were right. With the disk images renamed to HD00.hda the blue SCSI works perfectly. The loading of the 'key disk' animation is almost instant now.
In other news, I thought I had fixed the floppy drive as I found what looked like a broken trace on the small plastic ribbon cable from the head itself. I managed to solder it together (not pretty) so all the wires have continuity to the connector on the main board of the unit. I also check resistance and the two heads have the same resistances to ground for all five wires.
But, even though the 'flux' numbers are much better on Greaseweasle, and are pretty much the same for both sides of the disk, the floppy disk emulator shows the bad news..
But it is slightly better than before:
In this image the top pair are with the heads as they are in the first image. The bottom pair are where I switched the wires over to see if it was the heads themselves or the processing circuits that were at fault. Given that everything moved to the other side, I deduced it was the head itself at fault, hence the attempted repair.
I'm not sure that there's much else I can do with this drive so I'll hang on to it for spares but it won't be going back in the Torch.
And if you were wondering, this is the same disk, but imaged from the Cifer floppy disk drive:
In other news, I thought I had fixed the floppy drive as I found what looked like a broken trace on the small plastic ribbon cable from the head itself. I managed to solder it together (not pretty) so all the wires have continuity to the connector on the main board of the unit. I also check resistance and the two heads have the same resistances to ground for all five wires.
But, even though the 'flux' numbers are much better on Greaseweasle, and are pretty much the same for both sides of the disk, the floppy disk emulator shows the bad news..
But it is slightly better than before:
In this image the top pair are with the heads as they are in the first image. The bottom pair are where I switched the wires over to see if it was the heads themselves or the processing circuits that were at fault. Given that everything moved to the other side, I deduced it was the head itself at fault, hence the attempted repair.
I'm not sure that there's much else I can do with this drive so I'll hang on to it for spares but it won't be going back in the Torch.
And if you were wondering, this is the same disk, but imaged from the Cifer floppy disk drive:
philpem
Experienced Member
Can you post the makes and model numbers of the drives, please? That being the one you used to read the key-disk, and the one the Torch originally had?
And If possible can you also post the jumper settings on the Torch drive? A photo of the jumpers would be fine if that's easier.
And the current jumper settings on the Cifer drive, if you could.
My thinking is that things like motor spin (via MOTEN pin or when selected) are configurable on most 5.25in drives, as are the drive select IDs. The OMTI might be expecting them to be set in a certain way - say drive select zero (the default for a PC is select-1) - and your drive isn't set to what it's expecting.
Some drives also have termination resistor packs which will need to be added or removed. In general, there are things the Greaseweazle cares less about than older kit like an OMTI card might.
And then there's the chestnut of 40 vs. 80 track and double vs. high density... though if your Cifer drive is reading okay, that might not be the problem.
As for why the lower head might not be working after the solder repair - dumb question, but it's not dirty, is it?
A dirty head would give exactly the symptoms you're seeing - a bad read followed by no read.
And If possible can you also post the jumper settings on the Torch drive? A photo of the jumpers would be fine if that's easier.
And the current jumper settings on the Cifer drive, if you could.
My thinking is that things like motor spin (via MOTEN pin or when selected) are configurable on most 5.25in drives, as are the drive select IDs. The OMTI might be expecting them to be set in a certain way - say drive select zero (the default for a PC is select-1) - and your drive isn't set to what it's expecting.
Some drives also have termination resistor packs which will need to be added or removed. In general, there are things the Greaseweazle cares less about than older kit like an OMTI card might.
And then there's the chestnut of 40 vs. 80 track and double vs. high density... though if your Cifer drive is reading okay, that might not be the problem.
As for why the lower head might not be working after the solder repair - dumb question, but it's not dirty, is it?
A dirty head would give exactly the symptoms you're seeing - a bad read followed by no read.
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Drive models:
Teac FD-55FV-13-U from the Cifer.
Epson SD560 from the Torch.
The Epson drive had 'some work' when I re-capped it as the head loading was a bit sporadic. I might have moved the drive select jumper but I put it back where I think it should've been. Once again, the Torch manuals are a bit crap. Instead of saying, "Floppy drive should be unit 2" it says "jumper should be in position 3" but then shows a diagram where the jumper is clearly in position 2 which would make it drive 1.
Both drives are double sided doubled density (fortunately).
Above is the Epson drive. SS1 is the drive select jumper array.
This is the TEAC drive (the chips give it away!). The drive select jumper array is the one at the top of the picture.
The Epson drive already has a terminator installed. Not sure about the TEAC but I've no reason to think it wouldn't as it was the only drive in the Cifer.
And you could eat your dinner off those heads!
Teac FD-55FV-13-U from the Cifer.
Epson SD560 from the Torch.
The Epson drive had 'some work' when I re-capped it as the head loading was a bit sporadic. I might have moved the drive select jumper but I put it back where I think it should've been. Once again, the Torch manuals are a bit crap. Instead of saying, "Floppy drive should be unit 2" it says "jumper should be in position 3" but then shows a diagram where the jumper is clearly in position 2 which would make it drive 1.
Both drives are double sided doubled density (fortunately).
Above is the Epson drive. SS1 is the drive select jumper array.
This is the TEAC drive (the chips give it away!). The drive select jumper array is the one at the top of the picture.
The Epson drive already has a terminator installed. Not sure about the TEAC but I've no reason to think it wouldn't as it was the only drive in the Cifer.
And you could eat your dinner off those heads!
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Well, I think I've confirmed the bottom head on the Epson drive is borked. Specifically the read portion of the head.
I took an image of a known good disk on the Cifer drive. Then I connected the Torch (Epson) drive and took a second disk and erased it with the Greaseweasle. Then I wrote the image from the first disk to this newly blank disk and then took an image from THAT disk.
And guess what? The bottom side of the disk just does not exist according to the drive. It's completely red in the floppy emulator.
So, finally I swapped the drive back over to the Cifer (TEAC) drive and tried reading the disk that had been written on the Torch (Epson) drive. And the image was perfect. On both sides.
Conclusion - the bottom read head on the Epson drive is borked, but the erase and write heads are fine. In the spares box it goes...
I took an image of a known good disk on the Cifer drive. Then I connected the Torch (Epson) drive and took a second disk and erased it with the Greaseweasle. Then I wrote the image from the first disk to this newly blank disk and then took an image from THAT disk.
And guess what? The bottom side of the disk just does not exist according to the drive. It's completely red in the floppy emulator.
So, finally I swapped the drive back over to the Cifer (TEAC) drive and tried reading the disk that had been written on the Torch (Epson) drive. And the image was perfect. On both sides.
Conclusion - the bottom read head on the Epson drive is borked, but the erase and write heads are fine. In the spares box it goes...
Pernod
Experienced Member
Out of curiosity which disk image are you using, presumably one from https://bitsavers.org/bits/Torch/ ? And presumably the MFM_D5146 image?
I'd be interested in seeing what the SysV_Portable image does on actual hardware, as emulation gives an 'Icon file corrupted' dialog.
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
I'm actually using the image from the hard disk that came in the unit. I managed to grab it with the latest BlueSCSI. But now you say that, I might just give the others a try as I'm just stumped on why the floppy drive isn't reading the key disk.
I have a suspicion that the images from other Torch machines will probably complain that 'security has been violated' even if I can get the key disk loading but we shall see.
I might also try Caretaker 1.2 if I can find it - does anyone have it? - in case the 1.3 version is corrupted or the EPROM faulty in some way. And I can always try a new EPROM with 1.3 on again.
I have a suspicion that the images from other Torch machines will probably complain that 'security has been violated' even if I can get the key disk loading but we shall see.
I might also try Caretaker 1.2 if I can find it - does anyone have it? - in case the 1.3 version is corrupted or the EPROM faulty in some way. And I can always try a new EPROM with 1.3 on again.
Last edited:
Pernod
Experienced Member
I think I now fully understand the palette, can you confirm the initial shade of blue is correct? I'd always assumed it was the darker blue that was shown whilst the video RAM was being used for data transfer between CPU's.
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Thanks for this. I couldn't find it! I thought I'd got it from somewhere but obviously not.
I'm just trying to eliminate everything that could be wrong. I've written a new 1.3 EPROM but, as expected, no difference. I also tried the other disk images from bitsavers. The 'portable' image comes up with the error you described but if I click on the '=' symbol a couple of times it continues to the 'insert key disk' animation. The other image just goes straight to the key disk animation.
I did have a realisation that the OMTI controller is really only for MFM hard disks and the floppy drive. With the blueSCSI or the SCSI hard disk the thing gets to the key disk animation even without the OMTI powered or connected to the motherboard. I hadn't realised that before, so it does look like a big issue with the controller board. Darnit.
I'm just trying to eliminate everything that could be wrong. I've written a new 1.3 EPROM but, as expected, no difference. I also tried the other disk images from bitsavers. The 'portable' image comes up with the error you described but if I click on the '=' symbol a couple of times it continues to the 'insert key disk' animation. The other image just goes straight to the key disk animation.
I did have a realisation that the OMTI controller is really only for MFM hard disks and the floppy drive. With the blueSCSI or the SCSI hard disk the thing gets to the key disk animation even without the OMTI powered or connected to the motherboard. I hadn't realised that before, so it does look like a big issue with the controller board. Darnit.
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Yes, the light blue comes first. This seems to be at odds with the manual. But it's definitely light blue then dark blue when the Caretaker version is displayed. You basically get to the point I do now!
Witchy
Experienced Member
I was, so ta!
Actually sold some things which was nice, but I also had a good natter with Roland "Amstrad" Perry about his work since my stall was next to his. Good stuff.Pernod
Experienced Member
My emulation is now public as I feel it's at a solid checkpoint now, see https://github.com/mamedev/mame/blob/master/src/mame/misc/triplex.cpp
Pernod
Experienced Member
Just a thought ... your photos of the key disk screen don't show the red arrow to insert disk as in my video, so either you managed in multiple photos to snap whilst not shown as it's flashing, or it's detected the disk being present.
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
Sadly, it's my dodgy photography. I only managed to get the red arrow on one picture out of all of them I've taken!
I only managed to get the red arrow on one picture out of all of them I've taken!
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
A question for you @Pernod. On my Torch the SCSI ID on the OMTI board is set to 1, not 0 like the manuals suggest. Would you know if the Torch is 'hard wired' in Caretaker/ERMA to expect the floppy/winchester drives to always be on ID 0?
If I put the OMTI board as ID 0 then I get a 'trap' error. I'll have to get a picture of it later...
If I put the OMTI board as ID 0 then I get a 'trap' error. I'll have to get a picture of it later...
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
This is what I get if I set the OMTI board to SCSI ID 0:
I've tried re-configuring it by terminating the board as SCSI 0 so it's the only thing on the SCSI bus but I get the trap message above. Anyone got any idea what this means? Could it be a generic SCSI message, maybe the board is spouting garbage on to the SCSI bus?
I've also tried the (currently) working MFM drive I've got on the OMTI while it's id'ed as SCSI 0 and terminated. While I was looking at the card I also noticed that the two PLCC chips were dirty so I removed them (with the correct tool) and cleaned their pins but no dice in any configuration.
I've tried re-configuring it by terminating the board as SCSI 0 so it's the only thing on the SCSI bus but I get the trap message above. Anyone got any idea what this means? Could it be a generic SCSI message, maybe the board is spouting garbage on to the SCSI bus?
I've also tried the (currently) working MFM drive I've got on the OMTI while it's id'ed as SCSI 0 and terminated. While I was looking at the card I also noticed that the two PLCC chips were dirty so I removed them (with the correct tool) and cleaned their pins but no dice in any configuration.
Witchy
Experienced Member
Not a scoob. I can check my OMTI board if you think it'll help?
Crashedfiesta
Experienced Member
- Joined
- Apr 16, 2022
- Messages
- 165
If you've got a pic of the board and the jumpers that might be handy. The unit I have had some extras added (one very dead MFM drive and one nearly dead MFM drive) so it looks like my OMTI card was definitely on SCSI ID 1 from when I got it.
philpem
Experienced Member
"Trap" could mean a 68000 exception, and the "pc =" would be the program counter value. Without knowing more about the hardware, it's hard to say what it's executing - but I'd guess the Caretaker ROM.
If 0x14 is the vector address, that'd be a division by zero (a DIVU or DIVS instruction had a zero divisor).
If it's a vector number then it's a reserved vector and shouldn't have happened.
If it's an actual TRAP instruction code, then that can't happen either because the operand for the TRAP instruction is limited to 0 to 15 decimal (0 to F hex).
It seems like a value might be coming back from the Omti which is zero, and the Torch software isn't expecting it to be zero.
Looking at Pernod's Triplex driver, 0x100000-0x1FFFFF is RAM. The million dollar question of course is, what's at 0x102162? Is the Caretaker ROM loading something off the hard/floppy drive to that location? Or copying itself to RAM and running from there?
You'd probably have to disassemble the Caretaker ROM to figure out what was going on.
If 0x14 is the vector address, that'd be a division by zero (a DIVU or DIVS instruction had a zero divisor).
If it's a vector number then it's a reserved vector and shouldn't have happened.
If it's an actual TRAP instruction code, then that can't happen either because the operand for the TRAP instruction is limited to 0 to 15 decimal (0 to F hex).
It seems like a value might be coming back from the Omti which is zero, and the Torch software isn't expecting it to be zero.
Looking at Pernod's Triplex driver, 0x100000-0x1FFFFF is RAM. The million dollar question of course is, what's at 0x102162? Is the Caretaker ROM loading something off the hard/floppy drive to that location? Or copying itself to RAM and running from there?
You'd probably have to disassemble the Caretaker ROM to figure out what was going on.