PCW newbie!

[GeoffB17]

Hm, that's a useful idea.

I would suggest you do what Jon suggests, i.e. format a good, clean disk in your drive (if you can get DISCKIT to run there, mind you, which is the initial hurdle).

Then, having got the disk formatted, test copying files to it, and use the VERIFY option within DISCKIT.

If the disk works reliably with this format, then the problem is ONLY the alignment, everything else is OK.   Yes, it will prob not work on any other PCW, but this MAY not be a problem?

If the disk will NOT work reliably, then there are OTHER problems with the drive, and you may need to give up on it.

Geoff

[TynH]

If the head is out of alignment and you format a good disk, it should work reliably on the same drive it was formatted on.

I would then expect the newly formatted disk to be unreliable in other drives.

Good point!

What I'd do if I were you is to create a new boot disk and try to copy the CPM v1.5 system file to it, so you can boot into CP/M v1.5.

Computer says no:




Fired up my CP/M 1.14 floppy, started PIP and replaced disk. Unfortunately now luck.
I managed to list the DIRectory but couldn't start PIP from the CP/M 1.15 floppy either.
Simply not going to happen.

You will probably find that once you have your bulk setup done, transferring files to / from the PCW using Gotek images is cumbersome (this was my experience). My preferred method is Kermit and a serial interface (but then, I was developing the uIDE drivers so needed to be able to constantly transfer FIDs in development for testing).

If I didn't have a uIDE, I would use a Gotek or HxC but as a boot drive - definitely not as a file transfer medium.

Having used zmodem on the NC100 I'm not a huge fan. Sure it works but in my opinion it's hardly less cumbersome than using USB thumbdrives.
Mainly because it involves dragging an old WinXP Laptop out of storage (which is only kept to upload eprom files to my car's ECU) and run Hyper Terminal.
My main machine doesn't have an RS232 port and no means of using an USB converter either (driver issue).


The main problem however seems to be where to source a working CPS8256 from.

[TynH]

Reckon I ought to go through the Mallard Basic documents before typing silly stuff:

[JonB]

What you need is an FTDI based USB adapter. Works with Win 10 64 bit. But also, you need a serial port. Then no muckling about, plug into your main PC, transfer
the stuff over with Kermit, job done. No old laptops needed, though you will need a serial port for the 8256.

Like this: https://www.ebay.co.uk/itm/163561771022

What about the 8512? Maybe time to break it out and fix up its Drive A? Borrow the band from the 8256's drive you just overhauled?

[TynH]

The 8512 hasn't arrived yet, no need to salvage the 8256's rubber belt though. Naturally I did order more than one.


The USB adapter would be of little use to me, my desktop computer runs RISC OS and AFAIK there are no drivers*. I have several machines equipped with a RS232 port but they're either retro machines or over at my other place so not super convenient really.


Isn't it a bit of a moot point given the scarcity of RS232 adaptors for the PCW (and the centronics version at that)?




*Edit: I spoke to soon

SerialUSB
=========

SerialUSB provides a DeviceFS serial interface (SerialUSB<n> for USB serial devices

It supports the following USB serial devices:

CH340
CP210x
PL2303
FTDI

The first device found will be called 'SerialUSB:'. If more than 1 serial usb device
is plugged in they will be given names 'SerialUSB1:' 'SerialUSB2:' etc. To see if the
device is recognised

*SerialUSBDevices

will list the recognised devices.

SerialUSB supports the standard RISC OS DeviceFS serial interface so you can test
output with:

echo test { > SerialUSB: }

which will send 'test ' to 'SerialUSB:' by default 'SerialUSB:' is equivalent to:

SerialUSB#baud=115200;nohandshake;data=8;stop=1;noparity:

So if you only want to change the baud rate/handshake you just need to use:

SerialUSB#baud=9600:
SerialUSB#baud=19200;rts:
SerialUSB#xon:

[JonB]

I presume that is a utility for your RISCOS macine?

All you need to do now is keep an eye on eBay for a serial interface. The do come up from time to time. As far as I know they are all serial + Centronics adapters. The Amstrad one is called a CPS8256 and there's another one by SCA Systems that has a real time clock in it.

I drew up schematics and did the board layout for a CPS8256 clone but there wasn't enough interest to make it worthwhile to produce. It is designed to connect to the Z80 bus that my uIDE device uses, so could be fitted internally or externally using the uIDE expansion port adapter. Take a look: http://www.cpcwiki.eu/index.php/File:CPS8256_3D.PNG

Cheers
JonB

[TynH]

All you need to do now is keep an eye on eBay for a serial interface. The do come up from time to time. As far as I know they are all serial + Centronics adapters. The Amstrad one is called a CPS8256 and there's another one by SCA Systems that has a real time clock in it.

Err yes, thing is I don't have an edge connector port so it has to be a Schneider branded CPS 8256. AIU none of the UK versions would fit without extensive modifications.
They do come up on ebay as well but prices vary from around 50 to 90 EUR. Not exactly a bargain.
I've saved my search and turned on email notifications but not expecting anything soon.

I drew up schematics and did the board layout for a CPS8256 clone but there wasn't enough interest to make it worthwhile to produce. It is designed to connect to the Z80 bus that my uIDE device uses, so could be fitted internally or externally using the uIDE expansion port adapter. Take a look: http://www.cpcwiki.eu/index.php/File:CPS8256_3D.PNG

I read about that too (and the possibility of adding an RTC chip which would be even nicer to have!) but I was under the impression that you gave up on it (understandably) due to complete lack of demand?

[JonB]

That's correct.

This unit can be fitted to the Z80 socket using a shim. I did not add a RTC to it because the board size prevents it (RTC could be put on a different board, though).

The Serial / Parallel port was supposed to be the first in a series of add-ons that use the "Z80 bus" - essentially all 40 pins of the Z80 processor - and there are shims and expansion port connectors that expose this bus. You would then connect your devices - like uIDE, or the serial parallel port - to the bus and put the FIDs in the boot disk's User 0 area.

The problem is that while the uIDE is reasonably easy to build (and get components for), the serial / parallel ports use the Z80 DART and i8253 timer, both of which are not exactly common or cheap. I wanted to clone the original design so that the existing CP/M Plus drivers work.

So the upshot is, it would not be cheap to produce, or sell; and as there was ZERO interest in it (despite me putting it up on the uIDE page and talking about it) I let it go. That said, I did the board layout and routing so it might be in order to get a fabrication house to knock up some boards for testing... just haven't had time yet.

(Update: When I searched eBay for the 8253 I looked for "i8253", but if you look instead for "8253 timer" you get more results. But you are still going to pay ~£10 for these two chips alone, and that's before you buy the other components and board.)

[TynH]

So what's the deal with CP/M 1.15?
Fitted my Gotek drive (love it but more on that tomorrow) and played around with 1.15. It doesn't really want to load, blanks the screen with apparently nothing going on. This being a floppy *emulator* I forced an abort by simply deselecting the disk image. This seems to be the only way to finish booting.







It's trying to load something not present on my 8256, isn't it?

[GeoffB17]

Exactly.

We use version 1.15 (as in 1 point fifteen) for loading JonB's driver for his uIDE system.   This version is one (as well as later versions) that will do this.

At a point near the end of the process of loading the .EMS system file, the just active prog will look to see if there are any .FID (or .FIB) files available to load, and if it finds any, then it will load and activate whatever.   For example, the driver for the uIDE , or your dir listing shows I think A35.xxx which is a disabled (by renaming) driver for a 3.5" drive as A: (prob activate by renaming as A35.FID, the similar .FIB files are more to do with changing the speed settings for the drives which is a little more specialised).

So, at this point, the EMS prog is looking for any .FID file.   BUT, it's looking on A:, and there may not be enough CP/M loaded for it to tell the difference.

Jon may know more about this, and might be able to advise, but until you can get this sorted you'd be better to use an earlier version of the system that does NOT seek a .FID file.

However, looking at your screen, the EMS does seem to have completed it's load, and you have got a working CP/M, so it may not matter.   Depends on what would normally happen AFTER any .FID file(s) load

Geoff

[TynH]

Thought as much, thanks.
Well I was going to explore the depths of this machine tonight but man, I'm tired!
Being able to finally load something other than the operating system or Locoscript really is fun though:





Enough for today, I'm off to bed!

[GeoffB17]

I'm pretty certain that AFTER trying to load any .FID file, then the system will look for PROFILE.SUB and run that.   So, if the process drops out, then it might fail to do anything with PROFILE.SUB, which might be a problem.

That could be all, though?

On my PCW, loading the .EMS loads the uIDE driver.   The process THEN runs PROFILE.SUB, and this includes commands running from drives C: and I think J: (on the uIDE drives).   So CP/M is fully active, and the uIDE drives are fully active.

Your DIR listing shows PROFILE.ENG, which is a renamed (disabled) PROFILE.SUB, there is no PROFILE.SUB active now.   If you rename .ENG to .SUB you might test this?

Geoff

[JonB]

Try by all means, but I think if there is no PROFILE.SUB it just returns to the CCP prompt.  Function 17 of the BDOS is called "Search for first" and it's used to locate the directory entry matching the passed in file name: http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm#Function_17

So it's looking for a FID or FIB file (actually, any file that has a file type that begins with .FI). Not finding one shouldn't cause an error, so there is something odd going on. Maybe your Gotek is not properly configured..

[TynH]

Well I got nowhere, tried every possible permutation and failed miserably.
Even substituted J14CPM3.EMS or J12DCPM3.EMS with either J12CPM3.EMS, J15CPM3.EMT or J15CPM3.EMS from here:
http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/cpm-plus-1-11-1-5-download/msg141771/#msg141771


Always starts booting, then stops looking for a fid file in A>
Apparently fooling CP/M with an empty text file named test.fid doesn't work either.

[GeoffB17]

That's not right.

You refer to J14...   Is that one of the original system files (in effect, version 1.04)dating back to mid 80s.   If so, that version knows nothing at all about FID files, and will NOT be looking for one.

Please refer to the version ## that appears on the screen with the initial startup screen.   The number indicated by the filename is NOT reliable, as in it needs some 'translation'!!

Maybe you've tried a version 1.14 (i.e. the version immer prior to the 1.15 you tried) and that one may well know about .FIDs.

Looking for a FID is hard-wired into the system file, from a certain point onwards, and NOT before.

Details on John Elliott's web site, but this isn't 100% reliable.   John has not been able to check EVERY version (nearer to all with CP/M than with Loco) and when he says that FID support startes at version xx, it MIGHT have been a version just before that John has never seen.   Fair do!

Geoff

[TynH]

That's not right.

You refer to J14...   Is that one of the original system files (in effect, version 1.04)dating back to mid 80s.   If so, that version knows nothing at all about FID files, and will NOT be looking for one.

Err that's kinda the point. Neither J12DCPM3.EMS (early German version by Schneider) nor J14CPM3.EMS support FID files but boot on my 8256.
J12CPM3.EMS and J15CPM3.EMT (as uploaded by you!) support FIDs but don't boot on my machine. Renaming *.EMT to *.EMS doesn't help either.

[TynH]

P.S.: just found out what A35.fib and B35.fib stand for:


http://www.habisoft.com/pcwwiki/doku.php?id=en:hardware:perifericos:datatwin8


Makes perfect sense, when you think about it. Cp/M is looking for 3.5" drives A & B.

[GeoffB17]

Hello,

I'm losing track of just what you're trying to achieve here.  Need to go back a step or two and clarify?

I understand that you're trying to boot from the Gotek, but when you use later version of the system (as in .FID enabled) then you have a problem, as the system file (EMS or EMT is irrelevant) tries to load a FID but cannot find one and reports an error which it should NOT do (if it does not find a FID file it should just continue and NOT report an error).   This problem is something that needs investigation, but maybe not immed?

To get past this problem, suggested you use an older version of the system which does NOT use FIDs.   This should go right to PROFILE.SUB, and should NOT try anything re FID.   Are you saying such a system file is STILL looking for a FID?  Or what?

The old J14 system (actually 1.4, really 1.04 on later numbering) should be OK, and should NOT be looking for FID.   Did this work OK with the Gotek?

Geoff

[TynH]

Booting isn't the problem, ,,pre-fid" files work fine.
It does however mean that fitting an uIDE upgrade isn't an option.

[GeoffB17]

The FIB file is similar to the FID.

As far as I understand things, the FIB is used primarily to change the speed of the drive.   Not quite sure why.   I think that's it's more of a performance thing.   I have a 3.5" drive attached (as an option) to my PCW as B: and I've never used a FIB, so it's being presented exactly as a 3" CF2DD drive would appear.   Maybe the use of a FIB might run it a little faster, but it works fine as is.

If you use a DS drive with a 8256, then you may well need something to avoid problems, as there's code in the system which expects a SS drive as A: and will report an error with a DS disk.   Maybe you could have a file A35.FID as well, regarding this, but I think a file A35.FIB is for speed only.   I've looked at the code in such a file and the message on loading refers to speed, IIRC.

Geoff

[GeoffB17]

Aha, you're worrying about the NEXT bridge?

Hopefully, by then, we'll have worked out where the problem is coming from.  And 'sorted' it.

The FID system is totally optional.   By design.   If there is no FID, this should be perfectly OK, and the system should proceed untroubled to the next step.   It should NOT be reporting an error.   Maybe the Gotek is confused about something, maybe there is something wrong with the file found, but the message you illustrated (a number of postings ago) suggests file not found.

NB creating a dummy file would not help.   The FID has a very specific format, incl CHK, and a faulty file WOULD inevitably generate an error.   Better to have NO file at all.

Geoff

[GeoffB17]

Need to dig into this further, but I note that the problem error message is:

BDOS ERROR 17  Invalid Drive A:

while trying to find the *.FI? file

This is while using the J15 system, but please confirm, what 'format' of Gotek image are you using for this?   Is this an A: image (178k) or a B: image (703k)?   Maybe the system is getting confused.

I had problems when I was trying to use my 5.25" drive as A:.   I had discussions with John Elliott.   Seems that Amstrad kept changing the code to check the drive types, and depending on the circumstances, some variants worked better than others.   Got it working by using a version even earlier than 1.04 which did allow an effective patch to the system to disable the 'sided' check.

Geoff

[TynH]

Thanks for the explanation, much appreciated!
I think part of the confusion is really due to the fact that SD Microsystems sold me J15CPM3.EMS both on physical media as well as in digital form. No wonder the floppy didn't work (whereas the Schneider system discs did)! So now my legitimately purchased DSK won't boot, that's just not cricket.
Luckily the digital download only cost me a moderate GBP 2 but the floppy was actually a bit dear when you include ,,airmail" shipping (which only took around ten days). Harrumph.

[TynH]

Good point re image size!
All my regular DSK files are 178K. My image handling tool was unable to load the DSK as provided by SD Microsystems, complaining the file was ,,too large" (DD and EDSK aren't supported).
Doesn't mean I can't copy the file to USB of course. The disc did seem surprisingly large under CP/M as well though, show.com reporting ,,486k" (free?) space.


I did however copy the *ems/emt file to my regular sized discs without much success.




P.S. a DSK also by SD Micro is ,,cp/m utilities" which is 700 something k. This isn't bootable or anything but works fine on my 8256. So obviously the Gotek can handle these.

[GeoffB17]

More interesting.

The SD Microsystems disk is clearly a B: (703k) image and this would appear as a B: disk and this may well trigger disk type problems.   The image may have the same?

I boot my PCW from a 3" disk (normal A: format, normal boot sector) using J15, and this boots fine, and loads the .FID for uIDE fine, and then proceeds OK to the PROFILE.SUB.

Something in your setup is triggering the format/sided conflict.   I guess.  This is there to protect the user of the 8xxx series where the A: and B: drives are different, and is being - maybe - a little over-protective?   Which is why Amstrad kept changing the code/mechanics of the 'protection' to try to refine the check better.   But they never allowed for Gotek!!!   Which can happily be both formats at once!!!

Geoff