• Please review our updated Terms and Rules here

Torch Triple X c1985.

Not a lot. Just a programmer that supports them.

The 8048 and 8049 have no provision for protecting the ROM contents. Needless to say, that probably drove a lot of the cloning of the 8048 keyboard controller in the IBM PC.

If you've got access to one I can pop it in the BP Micro and get it read out. Happy to do it by return of post but I'd suggest Special Delivery both ways if we went that route. Though at least once it's read out, it can be programmed into an 8749 to make a replacement.
I have tried building a circuit that was suggested on the EEVBLOG forums but I can't get it to work. It could just be my lack of experience with the Arduino but all I get out of it is a bunch of '00's with a few 'FF's towards the end.

I makes me very nervous the thought of sending it out anywhere.. but for the benefit of everyone, and especially if it means it can be duplicated, I'll risk it. 😁

The chip in my keyboard is already an 8749 so I don't know if that makes any difference. 1000011992.jpg
 
I swore I'd never do this but I asked ChatGPT if the T48 programmer would read the D8749 and it says it should. Could a human confirm if that might be the case? It seems to think that it would read the same as an AM27C128....

I have a T48 so if it does work I could possibly save a lot of hassle for everyone. (Of course, I could get off my backside and go and grab it and just have a go.)
 
Well there's a couple of hours I'm never getting back... The T48 does NOT have any capability to read the NEC D8749HD that is in my Torch keyboard. So, unsurprisingly, ChatGPT was wrong again. @philpem if you wanted to PM me we can see about getting this over to you. :)
 
@Crashedfiesta do you have the original schematics that were scanned, that then you reproduced? The very last page has the keyboard schematic where the matrix just has numbers ... is there a missing page that tells us which keys these numbers represent?
 
@Crashedfiesta do you have the original schematics that were scanned, that then you reproduced? The very last page has the keyboard schematic where the matrix just has numbers ... is there a missing page that tells us which keys these numbers represent?

@Pernod There's no other information in the schematics. I was all ready to painstakingly beep out every connection to the D8749 and the 74159 until I realised that the numbers are printed on the PCB. 😄

See attached spreadsheet with photo of the keys. The only thing I think I missed is which shift is which but otherwise it should be correct.
 

Attachments

See attached spreadsheet with photo of the keys. The only thing I think I missed is which shift is which but otherwise it should be correct.
Thanks, that should be a huge help.

Don't suppose you traced out the mouse connector, as it doesn't seem to appear on the schematic
 
Thanks, that should be a huge help.

Don't suppose you traced out the mouse connector, as it doesn't seem to appear on the schematic
I didn't but I can do tomorrow.

I will pop the screws out and get some pics of the inside of the mouse itself too. Not sure if that will help but can't hurt to know what's driving it..
 
@Pernod I traced the mouse connector and the GND and +5v just go straight through (as you'd expect). There are only three wires in the mouse cable, GND, +5v and TX. The TX line from the mouse connector goes through a 74LS04 (two gates) and the into pin 3 (RX) of the D8251AC (USART). From there, it looks like the main TX line comes out of pin 19 of the D8251AC to pin 1 of the main keyboard connector via a 74LS04 (two gates again).

Hope that makes sense as it confused the heck out of me - not helped by an intermittent fault in my ancient cheap multimeter probes...
 
@Pernod I traced the mouse connector and the GND and +5v just go straight through (as you'd expect). There are only three wires in the mouse cable, GND, +5v and TX. The TX line from the mouse connector goes through a 74LS04 (two gates) and the into pin 3 (RX) of the D8251AC (USART). From there, it looks like the main TX line comes out of pin 19 of the D8251AC to pin 1 of the main keyboard connector via a 74LS04 (two gates again).

Hope that makes sense as it confused the heck out of me - not helped by an intermittent fault in my ancient cheap multimeter probes...
I was expecting both RXD and TXD from the USART to go to the main keyboard connector, as the Service Processor page of the schematic shows these go directly to the HD6303R on port 2.

The documentation seems a little ambiguous about the main keyboard connector, does it actually have both RX and TX as suggested by the schematic? Or does the USART only receive from the mouse and not the host via the keyboard connector?

I wasn't actually expecting a serial mouse, but does make sense now, did you open it up to see what's in there?
 
I wasn't actually expecting a serial mouse, but does make sense now, did you open it up to see what's in there?

I took some pics of the inside.
 

Attachments

  • PXL_20250628_165035392.jpg
    PXL_20250628_165035392.jpg
    1.5 MB · Views: 11
  • PXL_20250628_165102420.jpg
    PXL_20250628_165102420.jpg
    1.4 MB · Views: 11
  • PXL_20250628_165254329.NIGHT.jpg
    PXL_20250628_165254329.NIGHT.jpg
    1.1 MB · Views: 11
I took some pics of the inside.
Thanks, anyone familiar with this type of mouse, apparently based on an Alps UDA020134A but haven't found any info on it.

There were various serial mouse protocols in use at the time so anyone have any idea which this uses?
 
I'll have another go at tracing the mouse circuit through the keyboard. Those telephone style connectors are a pain to follow and I've found two different ways of reading the pin numbers on the things.

In the meantime, here's a couple of pics of it almost finished. There are a couple of things left to do:

1) Figure out what to do with the power supply. At the minute it runs from an ATX supply hidden at the back with a physical rocker switch that turns it on and off.
2) Redo the internal cabling. Since I put it like this, it insists in booting into low res mode which I can only assume is because the cables are putting some pressure on part of the mainboard somewhere that it doesn't like.
3) Add a slot in the floppy drive Gotek bracket to accommodate an SD card extender from the BlueSCSI so that disk images can be swapped more easily.

PXL_20250721_205311921.jpgPXL_20250721_205423751.jpgPXL_20250721_205943103~2.jpg
 
It's been six months and I've done some more stuff - anyone who follows me on BlueSky would've already seen this but here's the link to my later escapades with this thing:

https://crashedfiesta.blogspot.com/2025/09/torch-triple-x-part-11-highs-and-lows.html

The very latest on this is that I've now got a (very) primitive composite cable set up so that I can use it with a regular TV. The tiny Torch monitor is just a bit small and the bigger one I have has major issues (it looks like only the green electron gun is working and the picture is very dim) so being able to plug it into a modern TV is very useful. A new blog entry will be coming on that very soon.

But I also wondered @Pernod if you managed to get any further with the MAME emulator on this? If you still need any info on the mouse traces, let me know! Also, just for info, I worked out that for the disk image that doesn't ask for a key disk, if I don't move the mouse I can move the cursor with the 'diamond' key and cursor keys. As soon as I touch the mouse, this ability disappears.

Other things I've worked out:
  • For most of the disks and disk images I have the Gotek can only be read at startup. I assume this is because the Caretaker is somehow happy to take floppy signals from any SCSI LUN.
  • I have one disk image where the Gotek can be mounted and the floppy images accessed there but it will only work read-only.
  • Images of the Key Disk on the Gotek do not appear to work as .img files as converted by Greaseweazle using the Torch disk definitions taken from the technical manual.
  • But they do work if they are converted to .hfe format by the HxCFloppyEmulator application. This isn't too much of a pain since the Gotek is only used in my configuration if the Key Disk is needed at any point.
  • It is possible to re-install Unix by copying the startup disk image to the Gotek and onto the Blue SCSI (as FD20 with 'use LUNs' option switched on) then load the Key Disk and 'boot' which boots from the floppy. This seems to use to Gotek initially then during the startup it starts to access the image on the BS - I was just as amazed as you that this acutally worked.. Once the 'installer', such as it is, is running, each disk needs to be copied to the BS card and renamed 'FD20'. It's a right pain but the BS copes with multiple removal/insertions of the SD card without issue.
 
But I also wondered @Pernod if you managed to get any further with the MAME emulator on this? If you still need any info on the mouse traces, let me know! Also, just for info, I worked out that for the disk image that doesn't ask for a key disk, if I don't move the mouse I can move the cursor with the 'diamond' key and cursor keys. As soon as I touch the mouse, this ability disappears.
No further progress unfortunately. I don't have the mouse or keyboard emulated to move the cursor. Being presented with a screen that'll only accept a combination of diamond and cursor keys isn't very helpful for keyboard development/testing.
 
I think I have already everything.
It validates the key diskette and loads the kernel as seen on the screenshot, but hit mmu bugs.
680x0?

If you're using the Musashi emulator core, check out the fixes Sprite_tm did to it for their Plexus P20 emulator. There's at least one bug in the exception stack handling which they fixed. I keep meaning to pull that fix into FreeBee and see if it removes the need for the supervisor paging bodge.
 
Back
Top