Closed thejpster closed 4 years ago
Are these pure sector images (exactly 180k, 720k etc) or CPC DSK files (these are different sizes and have a text signature at their very start)?
They are DSK files, and start with the signature expected in your DSK driver file.
Those DSKs should work as is with no configuration. Just to see if it is a DSK parsing issue, here are the two images converted using HxC software into HFE format. Please see if these work any differently:
pcw180_dsk.hfe gave a BDOS error. pcw720_dsk.hfe worked OK (doing a DIR reports 'No File').
Actually I'm not sure I know which file is which. BRB.
OK, so I'm 99% certain 001 is the 180k disk and 002 is the 720k disk. As supplied, 001 gives a BDOS error and 002 shows no files. If I use disckit.com to format 001, the on screen count goes to 159, and the 7-segment counts up to 80. But aren't 180K disks supposed to be 40 tracks, single sided? It then throws an error. The 720K image formats fine.
I'm not sure how a 3" drive reports the difference between a 180K single sided disc and a 720K double sided disk, but maybe that's the issue.
I believe then that there is some other reason for your machine giving the error.
A quick Google brings this up, worth a look, it could be baked into CP/M that Drive B is 720k. There may be workarounds (I didn't read too closely): http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/pcw8256-with-hxc-floppy-emulator/
EDIT: It's possibly hardcoded or defaulting to 720k unless it finds some signature in track 0 of the disk to tell it otherwise. If it thinks a 180k disk is actually 720k, of course it will get upset pdq.
180k disks are indeed 40-track single-sided. The drive does not report the size of disk that is inserted. The filesystem, boot record, or some other on disk structure (probably in sector 0) must be used to detect that. It must be that which is going wrong. Either that section of the disk image data is not present or wrong, or your CP/M version is ignoring/overriding it at least for Drive B.
It may be that CP/M has decided it needs to double-step a 180k disk. That wouldn't work unless tracks are doubled up in the disk image....
I think either your 180k DSK needs to be doubled up on tracks (so that double-step commands go to the right track) or we need to convert to HFE with the double-step flag and then FlashFloppy needs fixing to obey the double-step flag. Sounds sensible? Are you wedded to DSK or happy to convert to HFE?
Double-stepping makes sense. I'm happy to convert to HFE, if there's a tool that runs on Linux.
It's not a drive B: issue as I've pulled drive A: and set the jumpers to S0, and I get the same effect.
The HxC tools have to be built yourself on Linux. For starters, here's your PCW180 DSK image with doubled tracks. See how that goes:
DISCKIT.COM
identifies that disk as 180K and if you run verify, you can see the Gotek display going up in 2s (0, 2, 4, 6, etc), while the on-screen track count goes up in ones. You can also do a DIR
(and it reports No Files
). Excellent!
So the only question remaining is, I guess - should we fix the flashfloppy firmware to divide all track counts by two if a certain option if a 40 track PCW image is detected, and/or is there a tool I can use to up-convert my 40 track DSK images to 80 tracks (where half the tracks are padding)?
Right there indeed is the question. The only image format that allows to specify double step is HFE. Weird double-step-on-some-condition options to FF probably aren't tenable.
The morally best option here is probably to use HFE but uou may need to see if you can build hxc software for Linux. Or I can provide a script for doubling up your dsk images. It's a bit more gross as track data gets doubled up, but probably works OK. Do you need to he able to undouble (or convert back from HFE) to be able to use your DSK files elsewhere (other tools or emulators)?
I have no immediate need to transfer files to anyone else, and if I do, I'm not against knocking up a bit of Rust or Python to chop out every other track from a DSK file.
Given that anyone who uses FlashFloppy with an Amstrad PCW9512 (or an 8512 if you're replacing driving B:) is going to have this issue reading 180K disks, a host=pcw
option which understands the difference between a 180K disk and a 720K disk (the only two disks that a PCW can read), doesn't seem too left field. Otherwise anyone who wants to download a copy of Batman, or Steve Davis Snooker, for the PCW will go through this same rigmarole.
Maybe. For now then I will upload the track doubling code to the source repo. It's just a scrap of python.
I don't know enough to be sure how PCW systems determine that double-step is required. It's a new area so I will tread lightly. I probably will implement the HFE double-step option however, as most people are happy to convert to HFE via the Windows/Mac GUI tool (also buildable on Linux) and I can then at least document that in the PCW section of the wiki.
I will leave this ticket open until I have done that (might be a week or two).
Do try the script on downloaded DSK images. It may not work (there are two flavours of DSK). Attach one to this ticket if that happens and I'll fix the script.
It didn't work on these two: disks.zip
Linux file
reports them as Amstrad/Spectrum Extended .DSK data
. All the ones that worked were reported as Amstrad/Spectrum .DSK data
.
Okay try the script now.
Bingo - thank you very much.
Both methods (convert to HFE, and double up tracks via Python script) are now documented in the wiki.
I've been reading the above with interest as I am currently trying (without success) to load 180k games on a 9512 using a Gotek. Has the double step issue been solved? My Flash Floppy firmware dates from 2018 so would using an up to date Flash Floppy file enable me to run these games or is there some code I'd have to input somehow.
Check this out https://github.com/keirf/FlashFloppy/wiki/Host-Platforms#180k-disk-images
And I would also update the firmware, even though I dont know now if it is a must
https://github.com/keirf/FlashFloppy/wiki/Firmware-Update
su 6. jouluk. 2020 klo 15.07 P5ychoFox notifications@github.com kirjoitti:
I've been reading the above with interest as I am currently trying (without success) to load 180k games on a 9512 using a Gotek. Has the double step issue been solved? My Flash Floppy firmware dates from 2018 so would using an up to date Flash Floppy file enable me to run these games or is there some code I'd have to input somehow.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keirf/FlashFloppy/issues/318#issuecomment-739500220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHXQGQ7RHZI5ENAGBEEKKR3STN6Y3ANCNFSM4KV5I3AA .
Thanks. Here's how far I have got: I have copied the raw code from https://github.com/keirf/FlashFloppy/blame/master/scripts/edsk_double_step.py into a notepad++ document named: 'edsk_double_step' and it is in a folder named 'python scripts' on my desktop along with the 180k game snooker.dsk. In the command prompt after typing: C:\Users\david>desktop>python scripts_edsk_double_step.py snooker.dsk fixed_snooker.dsk I just get an error stating desktop is not a recognized command. Please could someone tell me what I'm doing wrong? I got the Hello World simple python script to run so I know I'm not totally useless. Thanks.
You should type that line starting from python.
Got it, it's running fine now. Many thanks! Apologies for all the noob questions.
I have an Amstrad PCW9512 with a single 3" drive. I have completed the motor sense mod and built a 26-pin to 34-pin adaptor. The Gotek appears as Drive B: and I can read/write from 720k DSK files without issue so I know the drive is working. I can't, however, read 180K disk images.
If I create some test images with the following commands...
Disk 002 works fine, but 000 and 001 give the following error:
Here's a video of the LEDs while running - in this case it's a 180K image downloaded from the Internet (so it should be good...):
https://photos.app.goo.gl/KsjZLxr8AGQtMAAp8
The Gotek is running FlashFloppy 2.14. Is this a DSK format parsing issue? Do I need to tune some configuration? I'm running without a config file, so it's all default.
Any suggestions gratefully received.