Partition Manager

It reports “Line too long”

What on earth is generating that error, it doesn’t sound like a DiscOp error to me. Does anyone that’s fluent in the SCSIFS/FileCore source have any ideas?

posted the screenshots and debug code on JASPP

Thanks, some odd values being reported there, I’ll double-check the code.

Thanks, some odd values being reported there, I’ll double-check the code.

Doug, I can see the issue on the Iyonix. It’s not detecting ADFS::5 as being a Slave.

I lifted the code from HForm, which I’m not convinced actually works:

SYS"XADFS_ControllerType",Drive%-1 TO A%;F%
IF ((F%AND1)=0 AND (A%=4) THEN <Slave> ELSE <Master>

I believe HForm will see ADFS::4 as Master and ADFS::5/6/7 all as Slave using that code. Is there a better way to detect if a drive is Master/Slave?

v0.31 is up, I’ve modified it to assume ADFS::4/6 are Master and ADFS::5/7 are Slave. I’ve started added the Wimp code to handle mouse clicks, but hopefully haven’t broken anything.

What on earth is generating that error,

“Line too long” is from BASIC. Literally what it says on the tin. A line somewhere in the code is too long. Just over the width of a 1920×1080 screen.

I get it, sometimes, when !Crunchie or Basic crunch concatenates too many lines together. I don’t yet know which.

“Line too long” is from BASIC

How does the code below generate that error?

!&10000=4
!&10004=&B0800000
!&10008=&1D1
SYS "SCSIFS_DiscOp64",,1,&10000,&10100,&200

Maybe is is related to the “Arguments of Function/Procedure incorrent at line 548” (in “Wimp”) which I am seeing with 0.31

Does anyone know how to specify the second IDE controller with ADFS_IDEUserOp ?

Maybe is is related to the “Arguments of Function/Procedure incorrent at line 548” (in “Wimp”) which I am seeing with 0.31

That’s from me modifying the code to handle mouse clicks. I’ve corrected that error and upload v0.32

Does anyone know how to specify the second IDE controller

I guess thats why I only get one drive ,ADFS::4, on my Iyonix now with version 0.32?

Also am I right in thinking that IDEFS is not yet in scope?

Printout from RPC running 6.20 with Simtec Unipod and VPod

read_drives
===

CDFS
--
CDFS::0 found

plus:

*help idefs
==> Help on keyword IDEFS (IDEFS)
*IDEFS selects the IDEFS as the current filing system.
Syntax: *IDEFS

==> Help on keyword IDEFS (Module)
Module is: IDEFS 1.30 (03 May 2004)

Commands provided:
IDEFS

Filing system commands:
DeviceMap ListMounts Attach Unlock Lock StartupReport
*devicemap
Simtec 16/32 bit (EASI 32) IDE interface (slot 1, port 0)
0 Maxtor 6K040L0 39205MB 63 16 L 4
*

I guess that’s why I only get one drive, ADFS::4, on my Iyonix now with version 0.32?

Correct

am I right in thinking that IDEFS is not yet in scope

I’ve not added IDEFS yet. Assuming it matches this documentation I’ll quickly add it to the next release for testing.

Hi Jon,

I have put some more debug output on JASPP this time from a RPC running 4.39.

Tested 0.32 on a RPC running 4.39 with an ADFS drive attached to the internal interface and get the following error:

SWI name not known in “add_Drives_ADFS” at line 60.

The drive is called HardDisc4 but shared over ShareFS via an obey file in Choices.Boot.Task that does the following:

*Share ADFS::HardDisc4.$ Robin2

Also get the same issue on a A5000 using 0.32 but this time the error is reported as:

SWI name not known in “Add_Drives_ADFS” at line 163.

That is also shared via an obey file as a different name but I deleted the share obey file, rebooted and retried and it still gives the same error so it doesn’t appear to be causing the issue.

Hope it helps.

Updated: Debug code now placed on JASPP

v0.33 up with bugfixes for some of the reports that have been uploaded today, debug info for IDEFS so I can figure out if we can actually talk directly to the discs, and Wimp context menus on drives and partitions. The menus don’t actually do anything yet, they’re just placeholders where I’m coding up the Wimp frontend.

EDIT: I’ve not had time to test on anything other than a Pi, so expect new errors!

Assuming it matches this documentation I’ll quickly add it to the next release for testing.

Oh, no, it’s way more capable than that, including its own partitioning system.
http://chrisacorns.computinghistory.org.uk/docs/Simtec/Simtec_IDEFilingSystemIssC97.pdf

I should also point out that because Acorn took a really long time to come up with a format capable of more than 512MB, others devised their own partition methods. The Morley SCSI interface can do likewise.
http://chrisacorns.computinghistory.org.uk/docs/Morley/Morley_SCSIInterface.pdf (section 2.1).

In both cases, I don’t know if a drive that isn’t partitioned is created as a regular FileCore drive, or if it is a drive with a partition table containing one entry. I’ve never tried reading a device formatted on one system on another (I just assumed it wouldn’t work – like ADFS floppies in a PC ☺).

Good luck! ;-)

it’s way more capable than that

I need SWI’s to send ATA commands to the underlying drive, otherwise it can’t be supported unless the drive is already initialised.

I looked at both the SimTec and Risc Developments docs and the later could possibly be supported as-is, although it outputs the info in text (facepalm) so I’ll need to trawl the text and hope it hasn’t change in different releases.

The Simtec does not documented any SWI’s in the manual that’s on Chris’s Acorns.

Probably the best way to progress is for people with the respective cards to dump the IDEFS Module and post it on the JASPP forum. I can then see what SWI’s it supports and if it doesn’t provide low level access, I can reverse engineer the IDE interface.

Hi Jon,

I have uploaded debug on 0.33 to JASPP.

RPC 6.20 with Unipod and Simtec IDEFS does not show any discs and output only has CDFS::0 not found.

RPC 4.39 with ADFS shows the ADFS disc, 8GB, but shows it as unallocated.

A3010 using a Watford Interface, IDEFS and a SDCard drive unsurprisingly does not show anything.

A5000 3.11 with ADFS shows the ADFS disc, 203MB, but as unallocated.

Iyonix doesn’t show the 2nd disc as per 0.32.

How do I determine if a filesystem is using LBA addressing?

I know its passed as a setting to FileCore_Create but I can’t seem to find a way to find to determine if FileCore_DiscOp is byte or LBA once started. The documentation for DiscOp addressing is clearly incorrect as it doesn’t mention LBA at all.

Do I simply check if *_SectorDiscOp exists?

Probably the best way to progress is for people with the respective cards to dump the IDEFS Module

You can obtain the latest modules direct from the STD website

The SANFU download contains all the required modules AFAIK.

I will look to extract the Watford ones for diagnostic purposes only and on the basis they are not retained.

Do I simply check if *_SectorDiscOp exists?

I’ve assumed this is the only way to determine if LBA should be used within FileCore and updated accordingly. It now tries DiscOps in the following order: DiscOp64, SectorDiscOp, DiscOp

v0.34 should hopefully show more ADFS hosted drives. I’ve tested it on a RiscPC and confirmed both ADFS IDE drives appeared.

Thanks for v0.34 Debug text follows

Parameters not recognised at line 334

Log deleted

Parameters not recognised at line 334

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

!&10000=4
!&10004=&B0800000
!&10008=&1D1
SYS "SCSIFS_DiscOp64",,1,&10000,&10100,&200

I told you way back on page 5 what the problem with _DiscOp64 is.

There’s also a post here from 2012.

I’ve had a look at the SimTec IDEFS Module. It has IDEFS_IDEUserOp, but if I follow the code path, all it does is MOVS PC,R14 :|

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

IDEFS_GetShape returns with values in R0-R3
IDEFS_Command potentially returns with values in R1-R5
IDEFS_ATAPICmd doesn’t alter any registers

It’s going to take weeks to reverse engineer, so I’m going to take IDEFS out of scope for the forceable future.

I told you way back on page 5 what the problem with _DiscOp64 is.

To quote you:

Don’t be fooled by the presence of *_DiscOp64.
Last time I looked it didn’t actually do anything different to *_SectorDiscOp which is why it’s not used in Fat32fs.

Which doesn’t explain why it fails. Did you mean to say it can’t address beyond 256GB – which is what I suspect is the issue.

Exactly. Ben Avison explains it better than me here