• Please review our updated Terms and Rules here

Torch Triple X c1985.

Apparently, the LUN thing on BlueSCSI is a bit of a hack so the logs don't get updated properly. I admit I was fiddling with it in the warm house just looking at the logs when I started it up. I need to get out into the cold garage and do it properly.. 😁
 
Which BlueSky board have you got? I've already got a few spare Picos so could get one and try it out here. The code already has some OMTI support (it at least seems to log the special OMTI commands).
 
Working away for a couple of days but found the pics I took of it for my blog. I bought mine from flamelily.co.uk:

V2 Desktop Kit UK

All your retro SCSI and PCB needs in one place. New stuff for old tech.
shop.flamelily.co.uk shop.flamelily.co.uk

If you have Pi Picos floating around they do a kit with just the BlueSCSI (and a bit of soldering).
 

Attachments

  • PXL_20240218_205115277.jpg
    PXL_20240218_205115277.jpg
    1.5 MB · Views: 6
  • PXL_20240218_204958671.jpg
    PXL_20240218_204958671.jpg
    1.7 MB · Views: 6
So I have not managed to get the current BlueSCSI to get the floppy drive to boot. I've switched debug on as I wasn't sure of the format of my floppy image made any difference (I've tried .img and .imd). There's a fairly consistent pattern in the debug logs that I'm seeing regardless of the image format:

[10597ms] DBG -- BUS_FREE
[10597ms] DBG ---- SELECTION: 2
[10598ms] DBG ---- COMMAND: OMTI-5204 AssignDiskParameters
[10598ms] DBG ------ OUT: 0xC2 0x20 0x00 0x00 0x00 0x00
[10598ms] DBG ------ OUT: 0x00 0x03 0x4F 0x14
[10598ms] DBG ---- STATUS: 2 CHECK_CONDITION, sense 0x00002500
[10620ms] DBG ---- MESSAGE_IN
[10620ms] DBG ------ IN: 0x00
[10621ms] DBG -- BUS_FREE
[10621ms] DBG ---- SELECTION: 2
[10623ms] DBG ---- COMMAND: RequestSense
[10623ms] DBG ------ OUT: 0x03 0x20 0x00 0x00 0x04 0x00
[10623ms] DBG ---- DATA_IN
[10623ms] DBG ---- Total IN: 4 OUT: 0 CHECKSUM: 8
[10623ms] DBG ---- STATUS: 0 GOOD
[10637ms] DBG ---- MESSAGE_IN
[10638ms] DBG ------ IN: 0x00
[10639ms] DBG -- BUS_FREE

I have the OMTI controller manual so I've been picking through that and it looks like the OMTI command 'AssignDiskParameters' has a problem and then issues a 'RequestSense' command. But I have no idea how to decode that or even if I can. If I am reading it right then the requestsense message is triggered by code '0x00002500' and it asks for LUN 2 (second byte of the 'out' data - although the coding for the LUN itself is not clear in the manual). But then the data IN i.e. the four bytes in response is not shown in the logging.

Doe anyone know if I'm anywhere close with this? :unsure:
 
Update from the BlueSCSI BlueSky account. Apparently 0x2500 means :

#define SCSI_ASC_LOGICAL_UNIT_NOT_SUPPORTED 0x2500

So now I'm poking through the source code on github, trying to kid myself I have any clue how it all works... 😄
 
A workaround for this command (force lun=0) may be needed:

github.com

BlueSCSI-v2/lib/SCSI2SD/src/firmware/scsi.c at 24cc0fb957b984ebc756e5651e871bfdd2ad8168 · BlueSCSI/BlueSCSI-v2

Open source, open hardware, SCSI emulator using the Pi Pico PR2040 and Pico 2 RP2350 - BlueSCSI/BlueSCSI-v2
github.com github.com

With lun=0 it should be accepted and ignored:

github.com

BlueSCSI-v2/lib/SCSI2SD/src/firmware/vendor.c at 24cc0fb957b984ebc756e5651e871bfdd2ad8168 · BlueSCSI/BlueSCSI-v2

Open source, open hardware, SCSI emulator using the Pi Pico PR2040 and Pico 2 RP2350 - BlueSCSI/BlueSCSI-v2
github.com github.com
 
I think the BlueSCSI is giving an error status code (check condition) following the "Assign Disk Parameters" command for LUN 2. This is causing the host to then do a "Request Sense" to get information about the error. As has been said above, it looks like we'll need either a workaround or a proper implementation of this OMTI-specific command.

My kit has arrived and I just need to solder on the Pico so I should be up and running soon and then can hopefully start adding some fixes.
 
Sorry for the delay in replying but it's taken me a while to get a test harness working. My trusty RiscPC gave up the ghost so I had to dig out another one and get that up and running.
Anyway, it's now working with my BlueSCSI and I'm able to read a block from the hard drive image (SCSI id 0) and the floppy image (SCSI id 2). I've setup my bluescsi.ini file to map LUNs to ids and the floppy is being successfully read as ID 0, LUN 2.

Here's what my file looks like:

[SCSI]
MapLunsToIDs=1 ; On
EnableParity=0 ; Off
Debug=1 ; On

Next, I need to try sending it the OMTI Assign Disk parameters command - BlueSCSI should be able to handle this as there's code to recognise the command and then ignore it.

However, I'm confused about a couple of things:

1) The OMTI 5000 reference manual states that the LUN should be in bits 6 and 5 of the second byte for command 0xC2 with all other bits set to 0. So, for LUN 2, I'd therefore expect the second byte to be 0x40 but it's clearly 0x20 in your debug output.

2) The data being sent in your debug output most closely match those for a floppy/"flexible" disk (e.g. the 0x4F is the cylinder count - 1= 80 tracks) but the OMTI manual implies that 10 bytes should be sent (not 4 as you seem to be seeing) with the eighth byte being 0x80 to indicate a floppy.

One thing I have realised is that BlueSCSI needs disk images to be in raw format so the key disk needs to be converted from IMD to RAW. I've found a simple utility called imd2raw which seems to do the job.
 
Looking at the Caretaker 1.3 ROM image you posted, I see the following hex string at 0x2FDE: C2 00 00 00 00 00 00 03 4F 14 00 00 00 80 00 00

This looks correct as it's the right length and has 0x80 in the 8th data byte. I'm assuming that the LUN is added in later but haven't tried disassembling the ROM.

It might be worth seeing what happens if you configure BlueSCSI so that the floppy image is ID 1 (with ID->LUN mapping turned on).
 
That's interesting about the floppy disk image format. The Greaseweasle saves 'raw' images as multiple files in a folder i.e. one file per track but I suspect that's not what BlueSCSI would be looking for. I shall have a look for the imd2raw utility. 🙂👍
 
I've got my RiscPC to send the OMTI Assign Disk parameters command (0xC2) and BlueSCSI is happy to accept it as long as the LUN is 2 (second byte = 0x40). (This is of course with the FDD as SCSI ID 2 and ID->LUN mapping turned on.)

If I change it to send to LUN 1, I get the same "STATUS: 2 CHECK_CONDITION, sense 0x00002500" message you've seen. So, I think it's definitely worth configuring your BlueSCSI to have the floppy image as ID 1.
 
Awesome! Thanks Rob. I've just been out and collected some logs:

Floppy .img (created with Greaseweasle) as FD1
Floppy .img (created with Greaseweasle) as FD2

As you can probably guess, setting the ID to 1 didn't make it boot... 😟

I also tried converting the .scp to raw with Greaseweasle but it breaks the image into individual tracks and, unsurprisingly, BlueSCSI saw the first track and thought that was it (a 37kb floppy image)!

One thing I just realised is that I have the 'Quirks' switched on for OMTI. I suppose I should go back and re-do them without (if I get chance later I shall venture out again). And I'd just managed to find img2raw but you've saved me a job. 😄(y)

I can't thank you enough for taking the time to help with this. I've really struggled to even know where to start once it got to the 'insert key disk' screen. I'll let you know how I get on with the raw disk image and turning off the 'OMTI' quirks.
 

Attachments

It looks like your board is sending the Assign Disk Parameters command to each of the four possible LUN values so it probably doesn't matter which one is setup as the floppy (although I think 0,0 has to be the hard drive). So I'm guessing that there must be some other issue but I can't see any obvious problem in the logs.
 
Pernod said:
Using the HxC Floppy Emulator from https://hxc2001.com/download/floppy_drive_emulator/ you can convert SCP to RAW sectors file format (not Raw Kyroflux file format).
Click to expand...
The other option is to tell Greaseweazle to make a ".img" or ".ima" file, which will be decoded disk sectors.

As you say, a RAW file will be Kryoflux Raw, which is a flux image like SCP but with each track in a separate file. It's one level below the sector image the BlueSCSI will want.

There's no need to install HXC, though the user interface is a bit nicer than the command line. FluxFox and FluxEngine are even nicer still.
 
Last edited:
I have some bits from Torch including the “portable machine” suitcase + keyboard. Mine lacked the prom, but now since it is dumped, i will recap the psu or build a new one and give it a spin. Surprisingly the disk I have still works, may I ask for a high res photo of the mobo
 
You must log in or register to reply here.
Back
Top