Partition Manager

It also has IDEFS_ATAPICmd, IDEFS_Command and IDEFS_GetShape – documentation would be helpful.

CDBurn uses IDEFS_ATAPICmd for writer control, so I am sure I have the docs somewhere (Simtec were very cooperative back then). However, it will obviously only work for ATAPI devices (ZIP, MO, CD/DVD…), not for plain ATA devices.

Is there a way to determine if FileCore can’t go beyond 2^29 LBA? I’ll have to modify my code to indicate inaccessible partitions and cap FileCore/DOS to the boundary, but I’d like to future proof it for FileCore being corrected in the future.

sure I have the docs somewhere

If they include all the SWI, I’d appreciate a copy. I trust the SimTec implements CDFS enough that I won’t need to resort to ATAPI. I’ll post a request on StarDot, as I’ve seen the designers of some of the IDE Podules on there.

I think it’s a bug in SCSIFS, but we need to see something from the following that isn’t a BASIC error:

The code reports “Line too long”

Or should it be:

Program renumbered
Parameters not recognised

EDIT: Spotted this behaviour, two different results. I was initially tidying up and removing, what I thought were too many carriage returns from the cut and paste, but I now realise that I might have being removing a carriage return too many. What’s expected? ;) On reflection I think I know the answer.

Is there a way to determine if FileCore can’t go beyond 2^29 LBA? I’ll have to modify my code to indicate inaccessible partitions and cap FileCore/DOS to the boundary, but I’d like to future proof it for FileCore being corrected in the future.

I expect that when the low-level interface between FileCore and its block device drivers (ADFS, SCSIFS, RAMFS, …) is updated to handle that, a new bit will be used in the driver flags word to tell FileCore that it supports 64-bit addressing.

So to find out if a block device driver supports such access you could (once the new bit n has been specified by the implementor) go

REM ppw% = pointer to private word of FileCore instance for driver
REM Not using ADFS_MiscOp etc. because
REM not all drivers have a MiscOp SWI (e.g. RAMFS on OS 3.1)
SYS "XFileCore_MiscOp",6,,,,,,,,ppw% TO block%;flags%
IF (flags% AND 1) THEN 
  REM FileCore too old, doesn't support MiscOp 6 - OS < 3.6
  supported% = FALSE 
ELSE
  REM where n is the bit indicating 64-bit addressing. 
  supported% = block%!0 OR 1 << n 
ENDIF

Pedantically, the PRM doesn’t specify the unused bits of the flags word as being zero, but I think this will work in practice.

On reflection I think I know the answer.

Yes, no need to investigate further, we know the issue and I’ll amend Partition Manager to ignore partitions that are inaccessible due to DiscOp limits. It does actually state in FileCore_DiscOp64 that it is limited to 256Gb, but I was looking in FileCore_DiscOp64 Address which doesn’t state the limitation.

So to find out if a block device driver supports such access you could

We just need ROOL to allocate a bit ahead of the game – I’ll raise it in Code Review as I’m not sure if anyone is reading this thread.

I only found a small part of the IDE docs I used for CDBurn development – the APDL/MicroDigital/Baildon Electronics part (ideA, Blitz, Awesome, Mico, Omega…). I put the link to the archive here so that we can start the well-working decentralized random backup process…

https://www.huber-net.de/cd_docn.arc

Still searching for the Simtec IDE docs and the Yellowstone RapIDE docs I have somewhere.

v0.35 is now available.

It should handle FileCore limits and inaccessible drives. Partitions that FileCore can’t fully access will be coloured red, it will however still attempt to read volume names etc if it can. The code isn’t in its final state yet, but should hopefully trap the error Andrew is getting.

As there’s currently no way to tell if FileCore is 64bit, I’m considering attempting to read the last LBA in a partition as it will fail with a parameter error if FileCore can’t access it.

Thank you for another update v0.35. Partition Manager now work for me! :)

All my drives are now present, including the SSD. The ext4 partition is displayed as expected, the FAT partition is coloured RED with the disk space shown and the type reported as unknown. I’m assuming that’s because they aren’t mounted.

On my screen, the left hand column that contains the disk information and icons, the bottom line isn’t quite visible in each rectangle (the bottom border of each rectangle containing the drive picture and size data). Everything else looks good.

the FAT partition is coloured RED with the disk space shown and the type reported as unknown

Sounds correct. It’s attempted to read &1D1B0800000 to see if it’s a FAT partition, failed and flagged the partition as inaccessible and unknown.

As a matter of interest – is there a reader for Linux formatted disc’s from RISC OS?

Talk about formatting disc’s – presume it means initialising.

Found the Yellowstone RapIDE docs – they look a lot like the SCSI stuff.

https://www.huber-net.de/Yellowstone_RapIDE_ATASWIs.zip

is there a reader for Linux formatted disc’s from RISC OS

There was a Ext2/3 read only application called IscaFS by Marco Baye that would work on the Iyonix.

The website is not available but Wayback may help but as to a ext4 version I am not sure if there is one.

is there a reader for Linux formatted disc’s from RISC OS?

I’m not aware of one, but I don’t believe there’s been a real requirement until recently.

Talk about formatting disc’s – presume it means initialising.

Modern drives can be initialised, there’s no need to fully format drives as they all come pre-formatted.

Found the Yellowstone RapIDE docs

Thanks for both sets of files.

is there a reader for Linux formatted disc’s from RISC OS?

A couple of links to IscaFS here and here , includes source code.

It also helps to search your backups before posting as I have found my archive copy.

Here on the Titanium I get the error
Invalid device ID in “add_drive_ADFS” at line 48
The machine is unuseable afterwards and I have to reset.

The last lines in debug/txt shows:
ADFS::5 – IDE hosted drive
Slave

The last working version her is 0.30. So this seems introduces with
- Changed ADFS Master/Slave detection to use bit 1 of the drive number

Exactly the same happens here on this Titanium with v0.35.
Is the ‘IDE hosted drive’ the real clue? I would have expected it to be SATA.

Following on from my last post , it struck me, I didn’t try Partition manager with the FAT “Transfer” partition activated. I noticed a delay in Partition Manager’s start-up time. I discovered it had created a debug file:

Log deleted.

Here on the Titanium I get the error
Invalid device ID in “add_drive_ADFS” at line 48
The machine is unuseable afterwards and I have to reset.

Interesting, I’m not sure why an INQUIRY would cause the system to hang unless ADFS_IDEUserOp is waiting for a response.

Exactly the same happens here on this Titanium with v0.35.
Is the ‘IDE hosted drive’ the real clue? I would have expected it to be SATA.

“IDE hosted drive” is my debug text – nothing to do with the underlying protocols. RISCOS only knows about “IDE”, which in reality is actually ATA and it’s successors.

The ADFS code isn’t complete yet – I still haven’t figured out how to access drives 3/4. I suspect the hang is due to the code having no way to determine if a drive is Master/Slave or on which “IDE” controller and trying the wrong device.

My guess is that SATA is presented to RISCOS as a list of IDE drives on the same controller. I’ll look at the ADFS/ADFS4 source later to see if I can figure out how to determine the info I need, as I’ve not found it documented.

Here on the Titanium I get the error
Invalid device ID in “add_drive_ADFS” at line 48

Could you try v0.36 please and upload debug/txt if it fails. I’ve rewritten the ADFS handler to handle Primary/Secondary IDE controllers, Master/Slave and SATA.

Good news, PartMgr 0.36 does not crash on the Titanium.

ADFS sizes, except the first, are now reported accurately. Screen dump and debug are here.

Confirm. 0.36 runs fine on the Titanium here too!

PartMgr 036 gives the following error on an Iyonix with two hard discs and 2 DVD drives.

Previously 0.35 showed just one hard disc.

“Logarithm range at line 267”

ADFS sizes, except the first, are now reported accurately

Thanks for the report and logs, I’ll investigate the issue with the ADFS::4 size.

EDIT: It’s reported an LBA size of 1536, so the drive is reporting it has multiple sectors per LBA. I’ll add some further debugging output for the next release.

EDIT2: I’m actually calculating it wrong, it’s reporting 8 logical sectors per physical, so its a 4K drive

“Logarithm range at line 267”

Thanks, I’ll check the code. What OS version are you running?

What OS version are you running?

5.28 on the Iyonix