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
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
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
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
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 (http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/3-5'-floppy-head-alignment/msg139446)
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..
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
(Deleted post, incorrect info)
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
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...
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
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 (http://pcwwiki.amstrad.es/).
Thanks!
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!
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
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
Geoff,
Would it be the same as this one (http://habisoft.com/pcwwiki/doku.php?id=en:hardware:perifericos:intergem_disk_drive_interface)?
If indeed it is, there's no need for the pictures. I'd appreciate if you could scan the manual somewhere in the future.
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
I don't think we have the software either.
Are you able to image the disk?
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 ☹️
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.
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
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
The images referred to above are attached here.INTERGEN.ZIP INTERGEN.ZIP
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
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
Hi
@GeoffB17 This is quite fascinating for me. It's a real blast from the past. Unfortunately, I don't have any materials either code or anything else from those days, so I have to rely on my (very) imperfect memory.
I think I got an Apricot MSDOS disk from a customer, who had a machine with a strange, non standard format. Yours may be standard IBM format, or yet another strange Apricot format. Have you tried just treating it as a standard IMB disk ?
As for reading other format CP/M disks, you should be able to do this by patching the code in DRIVEB.COM. If you look at INTERG-A.DSK at offset 0x2130, you will find a list of names for the different formats. I have to admit it looks strange and I don't remember any of these formats. If you then look from offset 0x232e you have a list of 64 byte records corresponding (I assume) to the named formats. Only 27 bytes are used as the XDPB is only 27 bytes long. If you use the links I gave earlier and try to work out what the format of the disk is, then you could patch one of the named formats in the code. I have to admit that I don't remember how I worked out the format with no info, I expect it was just a matter of trial and error until I got something that looked sensible and then homed in on the exact format from there.
Just as a postscript to the whole InterGem thing, we selected Gemini Marketing to market the product. They had lots of experience with BBC and Amstrad stuff. We did due diligence on them including their last 3 years of accounts, which were good. In the end, they sold about 8,000 units in the first 6 months and we were due a royalty of £10 on each unit sold. The week before out first royalty payment was due, the MD and owner, a guy called Dale Hubbard emptied the companies bank accounts and ran off with it all to (we think) the US. There was very little left apart from stock and some office equipment. Everything else was leased. So, £80,000 up the swanny, and we didn't get a single penny out of it. In 1986 that was a LOT of money. Hey ho ....
Just found this for the Epson QX-10 format
https://fjkraan.home.xs4all.nl/comp/px4/vfloppy/epsonCPMdirectory.html
This may have all you need to generate a new XDPB.
As for the software working with other external drive units, it doesn't surprise me at all. The software just selects the disk format for drive B and mounts it. It can be any drive B that the machine recognises.
Also, Dale Hubbard ... he's on twitter >:( >:(
Thanks for the extra information.
I take it no-one was up to trying legal pursuit of the runaway? Problem I guess would have been the likely legal costs, vs the amount involved. Maybe never going to be worth it.
The QX-10 thing would be just out of interest. I use the 22DISK system, and I can get at the QX-10 format disks fine using that. I've got these disks as back then I was still using the Epson HX-20 and I had the TF-20 floppy drive unit, which used the same format, so I got a few PD disks with 'stuff' on. All still accessible. Once I'd got the BOX drive I got all the PD disks with that format instead.
But YES, it would be useful to get the PCW to directly read/write the 3.5" disks. I can do this OK now, again using 22DISK, but it's more of a fiddle using another computer, in another room. My main PC (internet linked) does have a 3.5" drive, so it would help to be able to transfer files PCW <--> PC (Internet) rather than PCW <--> PC (22DISK) <--> PC (Internet).
I've got all the disk definitions within 22DISK, I'm sure I can relate the info there with the data in your file, and maybe add any definitions required. I'll have a look into the data in DRIVEB.COM.
Thanks for your help.
Geoff
Hmm??
Looking at the data files/progs, I'm wondering if the data I need to 'fix' for the 3.5" DOS is actually NOT in DRIVEB.COM but is in MSCPM.COM or CPMMS.COM. The manual does not show any 'name' for the PC formats, and the two MS progs do seem to have XDPB type data in them.
As one of the Apricot formats is shown as 70T, and I understand that the Apricot format (which was 'almost' PC compatible) was 70T, I'd expect to see a value of 70 (hex H46) but I've not spotted that yet.
I'll keep looking.
Geoff
Quote from: GeoffB17 on 18:11, 29 April 22Hmm??
Looking at the data files/progs, I'm wondering if the data I need to 'fix' for the 3.5" DOS is actually NOT in DRIVEB.COM but is in MSCPM.COM or CPMMS.COM. The manual does not show any 'name' for the PC formats, and the two MS progs do seem to have XDPB type data in them.
As one of the Apricot formats is shown as 70T, and I understand that the Apricot format (which was 'almost' PC compatible) was 70T, I'd expect to see a value of 70 (hex H46) but I've not spotted that yet.
I'll keep looking.
Geoff
I think your right about using MSCPM or CPMMS to copy the non standard Apricot MSDOS format disks. I'll have a look at the code in the image to see if I can see anything.
Quote from: hairbear on 15:45, 30 April 22Quote from: GeoffB17 on 18:11, 29 April 22Hmm??
Looking at the data files/progs, I'm wondering if the data I need to 'fix' for the 3.5" DOS is actually NOT in DRIVEB.COM but is in MSCPM.COM or CPMMS.COM. The manual does not show any 'name' for the PC formats, and the two MS progs do seem to have XDPB type data in them.
As one of the Apricot formats is shown as 70T, and I understand that the Apricot format (which was 'almost' PC compatible) was 70T, I'd expect to see a value of 70 (hex H46) but I've not spotted that yet.
I'll keep looking.
Geoff
I think your right about using MSCPM or CPMMS to copy the non standard Apricot MSDOS format disks. I'll have a look at the code in the image to see if I can see anything.
Yes, you use MSCPM and CPMMS to read/write apricot MSDOS disks. Looking at the code for CPMMS.COMJ, it asks the question
Is your MSDOS disc :-a) IBM (or compatible) 5.25 inch ?b) Apricot 3.5 inch ?Please answer 'a' or 'b'I can't find any obvious XDPB info in the binary. To be honest, I'm not sure how the MSDOS formats were supported. There may have been some sort of RAW mode, although I would expect you would need an XDPB to at least map out the disk format. Maybe there is one in there.
Hello
@hairbear,
I attach the files for the InterGem system, so you can look at the actual files as opposed to the disk image.
I've copied them from the original disk using 22DISK, which has changed the *.COM to *.CPM to protect the DOS system from any unfortunate effects of actually running the wrong .COM. I've left the files like that for your benefit as well?
When I look in more detail at the CPMMS and MSCPM progs, which are supposed to support 6 different varieties of PC format (back in 1986 - keep remembering that) I note that there ARE 6 blocks of data, each of about 8 bytes, which seem to be a very partial XDPB. As these formats would be VERY similar to the PC formats anyway, I wonder if this part of the system did not try to replace a complete DPB, but merely adjust certain bits of the DPB?
Maybe there's a complete DPB data elsewhere in the prog, and THAT is adjusted, and then copied to the BIOS area?
Geoff
Thanks
@GeoffB17 . I've downloaded them and will look at them some time tomorrow. I'm in a different time zone to you (I think, if you're in the UK ?) and it's now wine o'clock :D .
Oh, just in case anyone wonders!
The earlier disk image, and the more recent .ZIP file, both contain a file SBBCCPM.ASM.
This file is NOT part of the original InterGem file set. This file was created by me, LONG ago, using a fairly BASIC Z80 disassembler. The file would need a LOT of work still to make a .ASM file that could be assembled, but it's a big help for working out what the prog is doing.
I'm sure that the other progs will have certain parts very similar to the listing I did late 1980s.
Just realised. So long ago! The BBCCPM was the original prog. The SBBCCPM.COM was a copy I created to try to make a single density version. The listing was done to help with that. So both SBBC*.* files are not part of the original system. I'm pretty sure that I made the image files from the original 3" disk, so these will not have either SBBC*.* file on.
Geoff
I've just had a quick look at MSCPM.COM. It hard codes the location of the drive B: DPB as 0FF65h, so will only work properly on CP/M versions with the 'old world' memory model (probably up to 1.5).
The XDPB it uses for Apricot disks is at offset 05E5h. The CP/M filesystem parameters in the first 17 bytes are not going to be massively significant -- the disk geometry in the last 10 is what matters. Similarly the XDPB it uses for PCDOS disks is at offset 05CAh.
Either way, it uses the first byte of the FAT to determine disk capacity. For Apricot disks it understands 0FCh (315k) and 0FEh (720k); for PCDOS it understands 0FCh (180k), 0FDh (360k), 0FEh (160k) and 0FFh (320k). There's then a table at offset 0530h with 8 bytes per entry giving the filesystem parameters: the four DOS ones first, the two Apricot ones second. I haven't gone so far as to work out what the 8 bytes mean.
John,
Thanks for your interest.
We need to record that these progs will be reliable with older versions of the system ONLY. I was using 1.07H so this will not have been a problem for me.
I was hoping to use the progs so that my PCW could directly access normal PC 3.5" disks, i.e. essentially the same format as would be on the 3" disk CF2DD. Save a bit of effort involving another machine running 22DISK. The prog as existing does not have this option explicitly, but offers the Apricot format. I understand that the higher capacity version is NOT exactly the same as a standard 3.5" PC disk. When I try this, I get a message saying the disk is NOT a suitable Apricot disk, so it's verifying the PC format, and I assume has not yet tried to set a suitable CP/M format up. Things I've read suggest that the Apricot formats were actually 70t, not 80t. Not sure if the prog is checking for 80t or 70t? Need to dif into it further, I'll prob do a simple disassembly of the orig (end up similar to the SBBCCPM.ASM file).
If it seems it might help, I could try (initially) to patch the prog to disable the initial PC format check. I'm not using an Apricot disk anyway!! Then see what the prog does when it sets the DPB for a CP/M format?
Obviously, it's more complicated than usual, as the directory structure is different, there's the FAT, and other things? I'd guess that the process would not care for User Areas and sub-dirs?
Geoff
I don't think it will work properly on 1.07H, because that has a New World memory layout.
The easiest way to patch it for 720k discs is to alter the code that checks for Apricot 720k. There's a CP 0FEh (FE FE) - if you change that to FE F9 then it should detect PC 720k discs instead. In MSCPM.COM this is at offset 0508h.
You will also need to change the filesystem parameters - in MSCPM.COM these are at offset 0558h. The Apricot ones are currently
81 02 03 0B 09 0E 00 00
For a PC 720k disc I think this should be
81 02 03 07 09 0A 00 00
(The meanings of those bytes:
81 - Sidedness. 80h for single-sided, 81h for double.
02 - Sectors per cluster. Must be 1 or 2.
03 - Sectors per FAT
07 - Sectors in root directory
09 - Sectors per track
0A - Sector number of cluster 0. Should be equal to (1 + 2 * (sectors/FAT) + (sectors in root directory)) - 2 * (sectors per cluster)
00 - Unused
00 - Unused
)
In general I can't recommend MSCPM as opposed to other PCW/MSDOS transfer utilities:
* It is hardcoded to copy files from B: to A: - all very well if your 3.5" drive is B:, but not if it's A:
* As mentioned above, it also hardcodes the address of the DPB so won't work with CP/M after 1.05 or so.
* As supplied, it can't handle PCDOS 720k format.
* It would need a thorough rewrite to handle discs with more than 2 sectors per cluster.
* It only uses the first byte of the FAT to determine the format, rather than the BIOS parameter block in the first sector. This means there are DOS discs it can't handle because they differ slightly from the 'standard' version of the format. For example, the DRDOS 6 installer floppy has a larger-than-normal root directory.
* It can only copy files from the root directory.
* There is a minor bug when, after copying a file from an Apricot-format disc, if you press 'C' to copy another file, it forgets it was an Apricot-format disc, tries to log it in as an IBM-format disc, and fails.
* It doesn't support CP/M 3 exact file sizes (but then, hardly anything does).
* Nor does it copy date stamps (setting an arbitrary CP/M date stamp is difficult but possible).
John,
Thanks VERY much for your work on this, and your comments - it's always useful to know these things. I would wonder however at the effect of time here, i.e. the general assessment might be different if it was done back in 1986 when this software was developed. For example, the hard coding of the DPB address was not ideal even then, but even Amstrad did not know how much change the 'system' would endure over the years.
Sounds like I could do something with this, but it might be more trouble than it's worth given that I can move files fine via 22DISK.
Geoff