avatar_Dan Dooré

PCW8256 with HxC Floppy Emulator

Started by Dan Dooré, 20:39, 03 November 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dan Dooré

Hi,

I have a 8256 (expanded to 512K) with an HxC floppy emulator as Drive B: and a A/B switch to swap the DS0/DS1 lines over meaning I can boot with either as the SSSD A: drive which is great.

The problem I have is that the B: drive always wants to be a 720k drive under CP/M, even with the B180.FIB file which just seems to be ignored, meaning that I can boot from A: as the real drive and use a DSDD disc image on the HxC as B: successfully or boot A: from the HxC with a SSSD image then switch the drives and use the real drive as A: and the HxC as B: with a DSDD but not both as SSSD :(

I have tried as many versions of CP/M as I can find but I'm going in circles a bit now as I don't know whether I'm doing the correct thing with the FIB file just having it on the boot disc.

Can someone point me in the right direction please?

Cheers,

Dan.

GeoffB17

What do you mean when you say the PCW takes no notice of the .FID?


You need a version of CP/M that will load a .FID.   Earlier versions will not even load the file, so as the lines are dropping down the screen on boot-up, there is no pause at the bottom, and you immed get the normal start-up info showing.   If the version does load the .FID, then there is a noticeable pause, you get the start-up info, and then an extra line or two relating to the .FID.


Does something actually load, but it doesn't make any difference. or does nothing load at all?


I have played with the A180 and the B180 files, and my machine will load them (using a suitable version of CP/M - 1.15 is the usual one I use), but the computer displays a message, but takes no notice.


It's possible the 8xxx series has something hard coded for A: being 180k and B being something else, although my machine works fine with B: being either 360k B: or 720k B:.   However, the 360k format requires the 'format' byte in the first 16 bytes on the disk to be 8x rather than 0x, maybe this signifies the non-standard disk type?


What's in the first 16 bytes of your floppy image, the one in the HxC, that you're trying to boot from?


Geoff

Dan Dooré

Hi Geoff,

Quote
What do you mean when you say the PCW takes no notice of the .FID?

You need a version of CP/M that will load a .FID.   Earlier versions will not even load the file, so as the lines are dropping down the screen on boot-up, there is no pause at the bottom, and you immed get the normal start-up info showing.   If the version does load the .FID, then there is a noticeable pause, you get the start-up info, and then an extra line or two relating to the .FID.

Does something actually load, but it doesn't make any difference. or does nothing load at all?

I'm using CPM 1.5 and 1.7 as the tests - I get no extra output on the screen at all - I have the file as a B180.FIB or B180.FID it makes no odds.

Quote
I have played with the A180 and the B180 files, and my machine will load them (using a suitable version of CP/M - 1.15 is the usual one I use), but the computer displays a message, but takes no notice.

That does not bode well :-(

Quote
It's possible the 8xxx series has something hard coded for A: being 180k and B being something else, although my machine works fine with B: being either 360k B: or 720k B:.   However, the 360k format requires the 'format' byte in the first 16 bytes on the disk to be 8x rather than 0x, maybe this signifies the non-standard disk type?

Most of the tests are with real SSSD disks in the B: drive as I'm booting CPM off the A: drive as the HxC - I've attached the boot DSK that I am using before it gets converted to HFE  to actually use.

Quote
What's in the first 16 bytes of your floppy image, the one in the HxC, that you're trying to boot from?

Not sure if that is from the DSK, the data as laid down or the HFE file, the second sounds the most likely so its (in Hex):

00 00 28 09 02 01 03 01 2A 52 00 00 00 00 00 04

Dan.

GeoffB17

Dan,


I've got your file/DSK ready to transfer to my PCW, but I've looked into the .DSK and looked at the .FIB, which I see does have a message, which I think should appear on the screen at boot time, regarding 180k B.


However, note that this B180.FIB is there to make a timing adjustment.   I think that's ALL it does.   I think this is a file needed for later machines, that assume a different type of drive.   The way you're using things, on a 8xxx series machine, I'm not sure this .FIB will do anything anyway.


The info in the first sector should be enough anyway.


I'll check further...


Geoff

GeoffB17

Yes, I think that the .FIB files are for the 9xxx series machines, which run the floppy drives with slightly different speed parameters.   The  .FIB adjusts something in CP/M to allow for this.   This should be quite irrelevant on a 8xxx system, also given you're using the HxC emulator anyway.


If you use the A/B switch, then the B: drive IS A:, and vice versa.   And I know that on the 8256, there is code in the system meaning that the A: drive does not like it if it finds a DS disk, or a DS drive.   This is a protection for getting the A: and B: disks the wrong way around.


When I was using my 360k (ds, 5 1/4" drive) as A:, there was a problem.  Tried different versions of the system, but only the early version would allow a 'patch' to the code (worked out by John Elliott) to disable this protection so that I could boot my PCW from a 360k drive (but using a correctly formatted SS 5 1/4" disk, with the correct boot sector for a SS disk).   The system was still spotting the DS drive!   My guess is that your system is doing the same thing.


Maybe you need the same patched 1.4 version as I have.   This allowed the boot OK, but it did give another problem in return, and I cannot right now remember what it was - it might not apply to you?


Geoff

Dan Dooré

Hi Geoff,

Thanks for looking into this for me, that all makes sense.

The main reason for wanting both drives active is so that I can boot CP/M and copy things across rather than anything more funky so a patched version of 1.4 sounds like it would do the job.  Do you have a link of can you post the DSK file here?

GeoffB17

Sorry, it wasn't 1.4 (should be presented as 1.04 ?).   It was in fact 1.01 that we were able to patch.   The routine was not the same in 1.4, I tried changing that, but it didn't work, and I think there was a similar routine somewhere else as well.


Anyway, the change to 1.1 did the trick, as far as allowing me to boot A: from a 360k drive/disk.


.ZIP with J11 should be attached.  Can you get this onto your PCW, or do you need a .DSK.


I use 22DISK for sending files back/forth between PCW and PC.


Geoff

GeoffB17

Dan,


I've looked through this exchange again, and I'm thinking I've been getting myself mixed up.


To clarify.


While I had the 5.25" drive as A:, and assuming the disk was correct, my PCW was booting fine.  The problems came after the boot, when I tried to access disks in A:, I was getting a disk/drive invalid error.  This problem was removed by the patched 1.01 system.   This system has no bearing on the actual boot.


Reading your original messages again, I think that you also had the system booting OK, incl from the HxC (B:) drive, while it was 'switched' and so was appearing as A:.   Is this so?


I would guess that, at this point, you would then have run into the same problem with the system seeing the drive (B: switched to appear as A:) show as DD (as per the real B:), and this would generate an error from the running CP/M.


If the above IS the case, then the 'patched' 1.01 system I've sent you will help, as it disables the drive type check, and the drive will always be seen as OK.


This version however will NOT help if there is in fact some problem with the initial load of CP/M.


I think by the way that you should disable/remove the .FIB, as I don't think it's relevant on the 8xxx machine.


Geoff

GeoffB17

Files attached.   Now.  Missed before.


J11 is just the patched system file.   The other file is your previous system .DSK, but with the .EMS changed to the patched version.




Dan Dooré

Hi Geoff,

Quote
Reading your original messages again, I think that you also had the system booting OK, incl from the HxC (B:) drive, while it was 'switched' and so was appearing as A:.   Is this so?

Yes, exactly that - and the Real SSSD drive is the CP/M B: drive

Quote
I would guess that, at this point, you would then have run into the same problem with the system seeing the drive (B: switched to appear as A:) show as DD (as per the real B:), and this would generate an error from the running CP/M.

Yes, and the same if I flip the HxC to be B: I get the same with an SSSD image but if I chose a DSDD image it reads it fine.  Interestingly when trying to read the SSSD image I can see the track seek all the way up to 79, the real drive does similar with a really pleasant grinding noise :(

Quote
If the above IS the case, then the 'patched' 1.01 system I've sent you will help, as it disables the drive type check, and the drive will always be seen as OK.

With the modified DSK or 1.1 loaded I get a slightly different error when trying to see B:, before I got B: Track 1, sector 0 no data etc. but with this I get CP/M error on B:  Disk I/O BDOS function = 14

This is with the FIB either renamed .XXX or not.

I also tried the FIB file from here http://www.z80.eu/cps8256.html just in case the one I was using was incorrect somehow.

This may be impossible although teasingly the above link explicitly states it should be good :(

Dan.



GeoffB17

Aha - I wish we'd determined that before.


Those messages are something else.   The problem I was suspecting gave rise to a specific Amstrad message, something along the lines of 'Unsuitable disk...'.   The messages you quote are general CP/M messages, NOT specific to Amstrad.   They suggest either a real problem with the disk/format, or a problem (hardware) with the drive.   For example, some confusion as to incompatibility between the expected format and the actual format.


I'll need to think further about that.


Either way, I still believe that the .FIB system is not relevant for your situation with a 8xxx machine.


Geoff

JohnElliott

As I understand it, B180.FIB was intended for the situation where a single-drive PCW8256 gets a switchable 3.5" drive fitted in the empty bay. Then when the 3.5" drive is A:, the existing 180k becomes drive B:.


There's a USENET posting from Howard Fisher <https://groups.google.com/forum/#!original/comp.sys.amstrad.8bit/R3UHuWJPlIo/vrxoIHYemikJ > in which he says he's never tried B180.FIB on a 9512. So if it wasn't intended for a 9512, it must have been intended for an 8000-series PCW.


If B180.FIB is loaded and active, you will see the message "180k 3 inch Drive B:" at CP/M startup.

GeoffB17

John,


Sorry, but I must question the above.   Based substantially on info from YOUR website!


Firstly, Dan is using an 8256 (although upgraded).   But he is also using a later version of the system, possible a version originally supplied with a 9xxx machine, to provide the .FID facilities.


I believe (according to your info) that the version he is is using MAY be one that is capable of using the higher disk step rate (for greater performance) , but I don't know how this would be activated, and I don't know if this change would be automatic - I do know that I'm using a later version on my PCW and the 3" drive works fine and the 3.5" B: works fine (and normally, and a bit slow ?) as far as I can tell, and the 5.25" B: also works normally so it SEEMS that the higher step rate is not implemented.


I understand from your info that it was the 9256 and 9512 that allowed this higher step rate, and maybe those machines implemented this change automatically (how ?), and for those, YES, if you wanted to attach an old 3" drive then you needed the .FIB - your docs on your website refer to the .FIB as being required specifically for this purpose, to adjust the drive parameters.


So, the evidence before my eyes (on my PCW) is that the later CP/M version alone does not force the step rate change, and I would suggest that if the step rate is not changed, then B180 would NOT be required.


However, how the order of start up - specifically the boot and the initial drive assignments, coupled with the later A/B switch, would affect things.   And how does the HxC appear to the system?   If you start the system with one drive config, and then switch A/B, how does that leave things.   I'd guess - confused?


NB - the comments on the newsgroup item you posted are correct, as they are referring to a 9512, and attaching a 3" drive to that (which would not normally have a 3" drive attached) and on my understanding of things, and my understanding of various things you say on your website, then YES, the B180.FIB WOULD be required to set the step rate back to 'normal' and allow the 3" drive to work.  But again, is the step rate set by the system (software), or by the machine (hardware)?   On my 8256 it seems to be set by the hardware.


Geoff

GeoffB17


Dan,

I'm not fully certain of tho details here, but...


When you start the system, the startup process will set the DPB for Drive 0 as A: type.   I'd guess that it will set Drive 1 as whatever disk type it sees in the HxC, does that support BOTH A: and B: types, and what type will be active at boot-up?


I think that the switch you refer to merely swaps the lines in the disk cable, so that Drive 0 becomes 1, and vice versa.   This does NOT change the initial DPB info.   A: is still A:, and B: is still B:, but they are connected (and activated/accessed) swapped over.   So, depending on the circumstances, the system could be trying to access A: using the B: DPB settings, and vice versa.


The PCW uses the XDPB facilities, and it can update the DPB from the disk, which for normal disks will get around this.   But, how does this work via the HxC?


When you start up, can you MAKE SURE that the disk 'set' within the HxC is an A: format disk, so that at that moment the actual disks in A: and B: are the same?


Geoff

GeoffB17

Dan,


Just thought to check your original .dsk that you posted.


I note that this contains the system file J17cpm3.ems.   Just to make sure, I've loaded this under John Elliott's 'Joyce' emulator, and I confirm that this is version 1.7 of the system file, and this version does NOT support .FIB or .FID files.


This is why (I guess) your system takes no notice of the B180.FIB file.   Where did you get that from, your system file would NOT normally come with any .FIB


If you need a version that DOES support .FIB and .FID, let me know.


Geoff

JohnElliott

I think this needs a bit more explanation.
In the beginning, there were only the 8000 series machines. Drive A: was always a single-sided, single-track drive, drive B: (if present) was always a double-sided, double-track drive, and this knowledge was hardcoded in the BIOS. This was the case up to about 1.7 (maybe 1.8; I haven't got a copy of 1.8 to check).

When the 9512 came in, there were now PCWs with a double-sided, double-track drive A:. Rather than hardcoding this, Locomotive made it more data-driven; each drive had an 'equipment' byte saying whether it was double- or single-sided, and double- or single-track. The functionality was internal to CP/M at this point, but Locomotive's +3DOS (published at around the same time) exposes it as the DD EQUIPMENT system call. At this point all step rates were still for 3" drives.

The 9256 and 9512+ had 3.5" drives, which prefer faster step rates. BIOS 1.11 / 2.11 added support for these. The detection code checks for a 9256/9512+ floppy controller; if it finds one, it checks that the drives are 3.5" and if so selects the faster step rates. If a 9256/9512+ floppy controller isn't present, the 3" step rates are used.

That all worked until third-party 3.5" drives started coming out, meaning that CP/M couldn't determine the drive type just from the PCW motherboard type -- and you could have PCWs where the two drives ran at different step rates. At first the drive manufacturers got round this by issuing patched versions of CP/M with the drives. Locomotive's eventual solution was the .FIB file, which can set the equipment byte and step rate separately for either  drive.

And now we come to B180.FIB. It sets the equipment flags for a single-sided, single-track 3" drive with the standard 3" step rates:

    cseg

    jp    FID_EMS
    db    1Ah, 1Ah, 1Ah, 1Ah, 1Ah, 1Ah, 1Ah, 1Ah, 'FIB'    ;Filename
    dw    102h                        ;v1.02
    dw    0F29h                        ;Checksum
    dw    0, 0, 0, 0, 0, 0, 0                ;Reserved
FID_EMS:
    ld    b, 5    ;Equipment flags: Single sided, single track, 3" drive
    ld    c, 1    ;Drive B:
    ld    de, timings
    ld    hl, 0
    call    SVC_D_SETUP
    ld    hl, message
    or    a    ;Do not remain resident
    ret
;
timings:
    db    10, 50, 175, 15, 12, 15, 3    ;Standard step rates for 3"
message:
    db    '180k 3 inch Drive B:', 0Dh, 0Ah, 0FFh

    end


Without B180, CP/M on an 8256 would attempt to drive the 180k 3" B: drive as a 720k 3" B: drive. That wouldn't cause a problem with the step rate, but it would royally muck up attempts to seek to the correct track.

GeoffB17

John,


Yes, I understand and agree with all of that, except the last paragraph, where I assume you're talking about system versions 1.11/2.11 and later where the higher step rate etc is possible.  For earlier versions, incl the version that Dan is using now, the higher step rate etc is not possible, as the .EMS/.EMT file does not support it.   Or is that not so?


The important thing right now, given Dan's setup, is - is the B180.FIB relevant or not?   I suspect that it is not.  Or does the HxC force higher rates on it's own, even on a 8256?


Geoff

JohnElliott

The ability to set different step rates / equipment flags for each drive was added in 1.11 / 2.11 (or maybe 1.10 / 2.10, which I don't have). And to load a .FIB file requires 1.14 / 2.14 or later. Earlier versions will ignore the .FIB file.

If Dan is using a 180k drive as B:, he will need CP/M BIOS 1.14 / 2.14 or later and B180.FIB.

I've never used an HxC on a real PCW, but there may be a separate issue with trying to us a 180k disc image after CP/M has established that the corresponding 'drive' can handle 720k disc images. I had the same problem with 3.5" discs formatted to 180k on real hardware. PCW CP/M expects:

* 180k disc in 180k drive: 48tpi disc in 48tpi drive, single-step.
* 720k disc in 720k drive: 96tpi disc in 96tpi drive, single-step.
* 180k disc in 720k drive: 48tpi disc in 96tpi drive, double-step.

The problem is that a 3.5" disc formatted to 180k uses 96tpi track spacing, not 48tpi. So CP/M shouldn't be double-stepping the drive. It's possible to override this behaviour by forcing CP/M to treat the disc as 96tpi. To do this at runtime, locate the XDPB for the drive and set bit 7 of byte 11h, and byte 1Ah to 0FFh. To do it permanently to a disc image, set bit 7 of the first byte of the boot sector (as suggested upthread).

DLOGIN (in XLOGIN.PMA on my homepage) forces all discs to be treated as 96tpi, but that's only suitable for a system where all the drives are 3.5".

GeoffB17

I think I'm getting clearer with this.


Dan, I understand, has a 3" A: and a HxC as B:.  No 3.5" disk involved.   I assume he has normal PCW A: and B: images on the HxC.


He can boot from A:, and use B: images on the HxC, no problem.


But he wants to boot from A: images on the HxC, and use normal A: format on the B: position, but cannot.   If he tries to do this, he has to switch drives after boot, which is not convenient.


In order to do specifically that, then under those circumstances, he DOES need the B180.FIB.   He will need that on his HxC boot image (type A:).   He does NOT need it when he boots from a normal A: floppy.


However, he does need a CP/M version that supports the .FIB load, as John defines above, i.e. 1.14/2.14 or later, otherwise the .FIB will be ignored.   Again, this version would be required on the A: image on the HxC, and would NOT be required on the A: floppy.


BUT, if you do swapping back and forth once the system is loaded, there might be problems?


Assuming the HxC will permit this, that might do the job??


I assume the 'speed' part of the .FIB would be irrelevant, but the other bit that adjusts the disk type would be needed?   i.e. the 'equipment flag'.


If Dan can get say 1.15 (which I have for use with JonB's uIDE system) then this should be a step forwards?


geoff

GeoffB17

Dan,


Depending upon what sort of images you're using on your HxC, it might be useful to have two separate boot A: disks, one with the .FIB on it, the other without.   You would use the former if you want to use 180k images on B:, and the latter if you're using normal B: disk images.


Geoff

Powered by SMFPacks Menu Editor Mod