News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_JonB

FID files

Started by JonB, 12:40, 26 December 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

JonB

I'm looking to understand FID files on the PCW (and presumably, the 6128).


So far, I have read john Elliot's introduction here: http://www.seasip.info/Cpm/amsfid.html , but there is much I would like to understand. What I want to do is add a cheap IDE device to the Amstrad machines and provide the device driver as a FID file.


This is a summary of what I learned so far:

       
  • The FID file itself is a CP/M PRL file with a special header and renamed with a .FID extension.
  • The first part of the header contains a JP instruction to the FID_EMS (startup routine).
  • To add a disk device, I would call SVC_D_HOOK (once per disk drive) and provide the address of the disk device jump table.
  • Thereafter, the disk device jump table itself plus implementations for each of the functions (FID_D_LOGON, FID_D_READ, FID_D_WRITE, FID_D_FLUSH and FID_D_MESS).
  • FID_EMS should return with the carry flag set so that the code stays memory resident.
Hopefully I have that right. So the questions, other than "Have I got the above points right?", are:

       
  • What is the addressing scheme for the .REL file? This means, things like the jump table have absolute addresses - how do I calculate them? What should the ORG be for the assembler code of the driver?
  • Is there any source code or example I could look at, preferably for a disk driver?
  • What is the limit on the size of the FID file (and/or memory)?
  • Where can I find out more?
  • Does a FID file work for both LocoScript and CP/M Plus? According to John's information, it should.
Thanks
JonB

GeoffB17

If you can work something more out on this, I'd be interested - for my PCW.


You might note my message regarding the HD facility for John Elliotts Joyce emulator.   About three pages back in this forum (for PCW etc) I posted a file for the CP/M version, which included the .FID file to add the extension for HD access.   That might be a useful example to examine?


Obviously, THAT version of CP/M had facilities to cope with THAT extension, so the extension is not JUST the FID.   But maybe there's a way around that?


Geoff

JonB

Thanks Geoff


I presume you mean this thread? http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/joyce-emulator-using-hd/


There's a DSK file attached - how do I use it? What I really want is the source to the FID file as an example. Still got it? Willing to share?


Cheers
JonB


GeoffB17

Aah - some folks here seem to do everything via the .DSK files, which is often far from convenient.


In this case, maybe you want JUST the .FID?


I'll try to attach it.


You can use it directly ONLY if the version of CP/M you've got will load .FID files.   The version in the .DSK file will do so.  But there are others.


This .FID is - I think - totally specific to the Joyce emulator, however the code there may help you.


The file is renamed as .ZIP, but it's NOT a .zip, it's .FID, so just rename it.


Geoff

JonB

I have it working, sort of - using PASMO to create the FID file, and John Elliot's FIDCSUM.COM to set the checksum in the file. It loads at startup, prints a sign on message, then exits. But unfortunately, I am now at a full stop, thanks to a bit of clumsiness: http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/3-5'-floppy-head-alignment/msg139446

JonB

OK, panic over  :doh:  and back to FIDs..!


I have completed the first cut of the driver code, but on loading the FID, the machine locks up. EXTRA-SHIFT-EXIT (the PCW Vulcan nerve pinch) will reset it, so perhaps it isn't entirely locked, but it never comes back to the prompt. This is where being able to debug a FID would be very handy. You can't call the BIOS from inside a FID, so you can't print stuff out to trace where it is going. That is a serious impediment to progress. That said, things like this are usually caused by me doing something stupid, so I will look again at the code, carefully..

GeoffB17

Hello Jon,


One thing you might consider.


Have you got JE's Joyce emulator?


This certainly handles .FID files.   Plus I think it does have some 'debug' facilities built in, and if something serious happens you may well get a Joyce error.


You could try - at least initial - development/testing on this platform.


There may be limits if the specific feature is totally inapprop to Joyce, but, it you don't get an error, then maybe it's OK?   Better than the real machine just locking up, which prob tells you nothing.


Just asking!


geoff

JonB

#7
(Deleted post, incorrect info)

GeoffB17

Hello,


Just doing a little digging for bits that might be useful for you.


Firstly, I noted somewhere (where??) in one of JE's pages about FIDs, USER Bios and system versions a passing comment that in BIOS version 2.9 FIDs were loaded at memory address xxx - but is other versions this address may be different.   2.9 is the system version I have, by the way.   Can't remember if you were ever wondering just where FIDs loaded (initially ?).


Secondly, I tried to see if there was any mention of the HD options for the PCW.   I understood that in the system's HeyDay, there were commercial options.   Don't know how many, but I found two:


ASD had a HD20 system, this used ASD.FID


Cirtech also had a system, this used HDRIVER.FID


If either of those driver versions could be found, it might be useful.


I think there was also a GEM system, but no reference to the driver for that.


Also, I note that one of the HD systems had a boot ROM, which somehow replaced the normal boot process and allowed the PCW to boot from the HD without using a floppy.


Interesting, some of the things that people managed.


By the way, if you've NOT got Joyce active, you could sent me the test FID and I'll see what happens!  That'll be on CP/M 2.9


Geoff

JonB

Interesting..

It seems that the "GEM" was made by Cirtech.

One of those FID setups (the ASD one) uses A0-A7 I/O addresses, and may work unaltered if I change the I/O base address of my IDE adapter to match. But it appears as if it doesn't use the IDE 8 bit mode according to what I read about it, which means you would lose 50% of your drive space, unless the AST adapter is feeding the upper and lower parts of the IDE 16 bit data bus in pairs to the PCW. If this were true, the FID could probably not be used unaltered (I seem to recall we had this conversation on the "PCW8256 Expansion port pinout" thread). However, I would like to use my own driver code and write the FID myself, because that is the point of the exercise - to overcome the challenge.

Just need to get past these blockers...




GeoffB17

Oh?


I have a GEM product for the PCW, it's made by Gemini.   No mention of Cirtech.


There could have been some connection, but Gemini and Cirtech seem to be quite separate.


The Gem product I have is a floppy disk interface for the PCW, so they were certainly into disk/add-on things.   I never used the interface (it was designed to fit where the drive B: should go) but the docs provided some useful into.  I got the package 'free' for some reason, not sure why now.


Geoff

robcfg

Hi Geoff!


Would it be possible to have some pictures of your interface and of the documentation?


I'd like to add it to the PCW Wiki.


Thanks!

JonB

Quote from: GeoffB17 on 14:29, 10 January 17
Oh?

I have a GEM product for the PCW, it's made by Gemini.   No mention of Cirtech.


OK.. I got that information from one of the pages that mentions the I/O port assignment. "Cirtech GEM" was mentioned as one of the drive types. Good to know there is a third option out there!

GeoffB17

Yes, I've checked and seen that.   Reference to the 'Cirtech Gem'.   Odd.


I'll dig further.


There's definite info about Gemini, who used the 'Gem' mark for products both for Amstrad and BBC add-ons.   No reference there to Cirtech, who as far as I can tell were a separate company.   If Cirtech had used the brand 'Gem' for one of their products, I would have expected they'd face legal action, unless they were simply selling a Gemini product, which is a possibility?


Nothing important now, other than academic interest.   And the question, were there two, or were there three?


Geoff

GeoffB17

Further to rob's enquiry, yes, I can do a couple of pics of the device.   The doc is a 40 page booklet which I'll have to see if I can scan it, but it's not something I can do readily.


The device is the Gemini InterGem for the PCW 8256/8512


Gemini Marketing Ltd of Exmouth


Device may be actually mfg by Dynamic Data Technology Ltd of Aberystwyth 1986.


Designed to be plug compatible with any BBC disk drive, so it presents the 34 ? pin connector rather than Amstrad's 28 pin.   You plugged the Amstrad's B: drive connectors (data and power) to the board inside the case, then plugged the external drive into the data/power connectors outside.


I was more interested in the info about disk formats etc.   I already had the BOX 5.25" floppy add-on by then.


Geoff

robcfg

Geoff,


Would it be the same as this one?


If indeed it is, there's no need for the pictures. I'd appreciate if you could scan the manual somewhere in the future.

GeoffB17

Yes, that's the device I have.


I've got the doc booklet, and the disk with the associated sortware.


So, it generates the ready signal OK does it.  I don't think I spotted that in the docs.   I'll have to try my 3.5" drive via it and see if it works?


Geoff

robcfg

I don't think we have the software either.


Are you able to image the disk?

hairbear

Quote from: GeoffB17 on 15:16, 10 January 17Further to rob's enquiry, yes, I can do a couple of pics of the device.  The doc is a 40 page booklet which I'll have to see if I can scan it, but it's not something I can do readily.


The device is the Gemini InterGem for the PCW 8256/8512


Gemini Marketing Ltd of Exmouth


Device may be actually mfg by Dynamic Data Technology Ltd of Aberystwyth 1986.


Designed to be plug compatible with any BBC disk drive, so it presents the 34 ? pin connector rather than Amstrad's 28 pin.  You plugged the Amstrad's B: drive connectors (data and power) to the board inside the case, then plugged the external drive into the data/power connectors outside.


I was more interested in the info about disk formats etc.  I already had the BOX 5.25" floppy add-on by then.


Geoff
Old thread I know, but I'm the guy who designed the Intergem in the dim and distant past, when I was young 🙂. It was designed to, and did, work with any Shugart SA400 compatible floppy drive whether 5.25 or 3.5". All it really did was take the existing Amstrad interface and create a reliable INDEX signal, which the Amstrad 3" interface didn't have, and was required for the SA400 interface. The software supported about 80 different CP/M machine disk formats as well as several BBC Micro and IBM PC disk formats for read and write. The software didn't use a separate driver at all. CP/M had a specific data structure that was used to define the data format on the disk. The software just manipulated this data structure to enable support for all the different formats. Unfortunately, I don't have the original software, and can't remember exactly how this worked.
I think that this link may be a good start

http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch6.htm#Section_6.10

I think you basically could remove the disk, change it's format and then connect the drive again. Again, not a clue how I did this unfortunately ☹️


hairbear

These two links show the basics of how I got the different disk formats working on the PCW.

https://www.seasip.info/Cpm/amsform.html
https://www.seasip.info/Cpm/xbios.html

It's all about getting the XDPB correct for the disk format you require. I seem to remember that I had people from all over sending me formatted disks from various machines that I analysed and added to my database of formats.

GeoffB17

Yes, I note the new info.  Thanks.

I now spot that I took the question about doing an 'image' to refer to a picture, now I'd understand the image to refer to creating an image file of the disk.   Yes, it that is needed, I could do that, using JE's DU54.

This thread WAS back in 2017!!

Geoff

GeoffB17

Further to this.

I've done the images, two sides of the CF2.

Side A  is the InterGem software, Side B is the Space Invaders game.  I'll get these transferred to PC, so I can zip them and attach them so you can add them to your archives.

Do you need the pretty disk pictures.   I can try and get a couple of photos, and you can maybe manipulate them as you need?  The disk just has a sticky label on top of the mfg label, with the bare minimum of detail printed on - fairly home-made look.

Geoff

GeoffB17

The images referred to above are attached here.You cannot view this attachment. You cannot view this attachment.

GeoffB17

Oh!!

Well, reading the comments from @hairbear above, I wondered.

I've had the InterGen bits ever since god knows when, and never done anything with them apart from looking at the code.   I always assumed that the 'magic' was in the interface.   I never installed it, as I already had the BOX 40T 5.25" drive B:.   I never thought that the software would work with the drive as-is.   No interface involved.

But reading the comments, and maybe understanding a lot more about the XDPB etc, I just wondered.

So, I've just tried it.   And it works perfectly.

Obviously, I can do things ONLY with 40T disks, as that's what my drive it.

I've just used the MSCPM utility, with a 360k DOS disk in B:, and it game me a directory of the DOS disk, I've then copied a file from the DOS disk to a DP/M disk, and that works fine.

Somewhere, I've got a stray BBC disk, if I can find it, I'll try that.

I've got various other CP/M disks, but mostly a format that InterGen does not support (Epson QX-10), others may not be 40T.

I need to check regarding the 3.5" disks.   I can attach a 3.5" drive instead of the 5.25" drive.   However, the InterGen system says it supports IBM formats for 40T only, but it refers to supporting Apricot 3.5" diskd for 80T DS.   The system DOES come from 1986, and it could well be that at that time PCs had not appeared with 3.5" drives, but Apricot had?

Geoff

GeoffB17

I've now tried the 3.5" drive, and this doesn't work.   System says that it's not a valid Apricot format, although the capacity is the same.   Pity - this would be useful if it did work.

I'll have to look at the details, maybe there's a way to patch the prog, or the format details.

The drive works fine as a normal CP/M B:, with a CP/M formatted disk.  The formats are very similar anyway.   If the 5.25" disk works, then the 3.5" disk should work as well.

Geoff

Powered by SMFPacks Menu Editor Mod