FID files

Started by JonB, 13:40, 26 December 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

hairbear

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 ....


hairbear

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  >:( >:( 

GeoffB17

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

GeoffB17

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

hairbear

Quote from: GeoffB17 on 20: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.

hairbear

Quote from: hairbear on 17:45, 30 April 22
Quote from: GeoffB17 on 20: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.


GeoffB17

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

hairbear

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 .

GeoffB17

#33
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

JohnElliott

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.

GeoffB17

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

JohnElliott

#36
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).

GeoffB17

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

Powered by SMFPacks Menu Editor Mod