News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Locoscript and .FID Files

Started by torrind, 23:23, 24 April 19

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

torrind

Hi All,

Quick question - I currently have version 2.12 of Locoscript running. I cannot seem to be able to use XDRV.FID to init uIDE. Does anyone know which version of Locoscript .EMS does this please?

Thanks,

Darren

GeoffB17

Hello Darren,

I've got a version of Loco 2.28, which works fine with uIDE.   Well, fine-ish.

As I noted else where, there is a problem with Loco and uIDE.   Loco sets out to read ALL the disks attached, and create the screens for the Disk manager within Loco.   For the usual disks, this isn't a big deal.   But if you've got the uIDE, then there's 8 user areas on 13 disks, and it takes an AGE!!   I got JonB to do a special version of the uIDE that used 3 drives ONLY, C:, D: and E: so that it's not too bad.   BUT, I've still got a lot of files on my C:, D: and E:, so it's still enough!!

Geoff

torrind

Geoff to the rescue again!  ;D


TBH, I would prefer to have fewer uIDE drives myself as I'm not ever likely to use all of them - Is there an easy way to achieve this?




Darren

JonB

#3
Yes. You get the FID to stop allocating drives when it reaches a specified number. Problem is, you can't tell it what that number is at run time as far as I know, so you have to have a specially built version that stops the allocation loop when the magic number is reached. also, it allocates from C: onwards and I can't alter that. So if you only need 3 drives it's C: D: and E:.

Of course, having a normal FID on a CP/M boot disk restores all drives. So all those files in the user areas I loaded the DOM with, you could move to higher drives for CP/M use only, and reserve the lower drives for your LocoScript files.

So, how many drives do you need for your LocoScript FID? If 3, then use the attached file (supposed to allocate 4 drives - it's the one I sent Geoff but maybe it has a bug and only allocates 3?)

@GeoffB17 - actually 16 user areas per drive but not all are populated.

[attach=1,msg173769]

torrind

Thanks Jon -


Just tried and it correctly allocates 4 drives (C D E and F)


Rather than keep bugging you - is amending the .FID easy (ish) to do should I want to have a play?



Darren

GeoffB17

#5
Aaaah, Jon,

For CP/M, yes, it's 16 user areas.

But for LocoScript, it's only 8.   The other 8 are used for 'Limbo' files.

But then, you don't use LS, so you'd not be familiar with that??

Regarding my 'special' .FID, yes, it does do 4 drives, but I was bothered only about E: which I cleared out on my system to leave it free for Loco files.   So I was thinking 3 when I should have remembered 4.

Geoff

GeoffB17

Just as an aside to this thread, when I decided to try to get Loco working with the uIDE, I checked the doc for John Elliott's Joyce as there was reference to the version of LS needed to use .FID files.   The doc said 2.30- but I didn't have 2.30 - but I did have a copy of 2.28 with LocoFile.   So I thought, well, it's only two versions before, wonder if this works.

So I tried it, and YES, it did.   Worked fine.

I sent a note to John Elliott.   He pointed out, not unreasonably, that he'd never had ALL versions of LS to test, and the earliest one he'd had that did work was 2.30, so that's the one he used referring to '2.30 or later'.  Fair enough!!

Geoff

JonB

#7
Quote from: torrind on 22:11, 25 April 19
Thanks Jon -


Just tried and it correctly allocates 4 drives (C D E and F)


Rather than keep bugging you - is amending the .FID easy (ish) to do should I want to have a play?



Darren

The FID is a set of routines written in Z80 assembler with a special header at the start followed by a vector table. You can patch it if you are handy with a binary file editor. Open XDRV.FID and look at offset 01C0h. You should see a sequence of hex values: AF 03 3C FE 10. The 10 (hex) is the maximum number of drives the FID can theoretically allocate (16, as in A: to P:). If you reduce this value and save the file down you can choose any number of drives you like (up to 16 of course.. well, the maximum uIDE drive count is 13 because you have A: B: and M: already).

Don't forget if you are patching XDRV4.FID the sequence is AF 03 3C FE 04.

It wouldn't be too hard to write a utility to do this.

JonB

Quote from: GeoffB17 on 22:20, 25 April 19
Aaaah, Jon,

For CP/M, yes, it's 16 user areas.

But for LocoScript, it's only 8.   The other 8 are used for 'Limbo' files.


Ah yes, I forgot...!

torrind


Hi Jon,

Well mixed results here.


If I edit the xdrv4.fid and change the value to 03 (or any other value 01,02,05 etc) from the default of 04, the driver fails to load. If I change it back to 04, it works.


Is there another part of the .fid that needs amending too? or am I missing something silly?


Darren

JonB

No, Darren you are not missing anything - I am.

The FID contains a checksum which will cause it not to load if it doesn't match the actual checksum on the file. So by patching the file you are ensuring the checksum test will fail. D'oh, I forgot all about that, sorry. What a Norbert.

So, the way to get round it is for me to produce additional FIDs with the requisite drive counts. Please let me know what drive counts you need, and I will produce them. Don't worry, it's easy (I have a good build system).

JonB

Oh, what the heck. I just built XDRV.FID 1-12, see attached. The number indicates how many drives it will allocate, with the xdrv.fid you already have allocating the full 13.

[attach=1,msg173804]

Now you can have your cake AND eat it!

:D

torrind

Thanks Jon,


TBH, I thought it was related to a checksum issue when I performed a checksum review from the 'default setting' to my new updates and they differed, but I was unsure how to get around this to make it work.


Thanks for doing this though, much appreciated.


BTW, how do you get around the checksum issue? Could I load the .fid into a z80 assembler and change it that way?


Darren

JohnElliott

Run FIDCSUM.COM (linked from here) on the modified FID file.

torrind

Thanks John - I'll give that a try.


Darren

torrind

Brilliant!


That worked a treat John - Running FIDCSUM against a .FID file that has a wrong checksum fixes it.


Although Jon presented me with a solution (and I'm very grateful for it) - At least I know how to cure .fid files with incorrect checksums in future should I start messing around.....


;D


Thank you.


Darren

JonB

Thanks John, I should've known that. It's been a while since I was in FID land!

Powered by SMFPacks Menu Editor Mod