• Please review our updated Terms and Rules here

GOTEK (drive B - external) problems

cj7hawk said:
Disk Images

en:sistema:indice [PcwWiki]

www.habisoft.com www.habisoft.com

Have a good look around that site - It's pretty amazing.
Click to expand...

Yes, I found this site earlier today :) Thanks!

GeoffB17 said:
Regarding the file image above, yes, the 'JOY' text suggests that this is a LocoScript document. Pity that you show a text representation, as the two bytes immed after the JOY would be two binary numbers, and could well indicate the version of LocoScript used, which could be a hint as to which PCW version is involved.

Regarding the disk being single or double sided, note that either might use CF2 disks, which COULD be formatted as DS. If this works, then the disk is OK for use as DS, if doesn't work, then use as single sided only. Many people used CF2 disks as if they were CF2DD. Both disks came off the same production line, some were tested for CF2DD format, and if they passed they were labelled as CF2DD and sold as such at a higher price, but many disks NOT tested could have passed if tested.

I have CP/M Box as well as Joyce, and I have boot images that work with both if you can't find anything. I'm sure there are enough OK images around though.

Regarding the query about the track numbers, yes, the CF2 format runs from 0 to 39, and that's what shows on the screen during formatting/copying. Another system might show this as 1 to 40. The physical drive and the physical disk COULD be capable of accessing a couple of extra tracks, and some software COULD try to access extra tracks to see if they were there. There are 'special' format versions for PCW disks that use the extra tracks to allow for higher capacity disks (still CF2, but 41 or 42 tracks formatted), but this is not always reliable.

If you have a disk and the label on each side shows different things, then assume this is an A: disk with two separate sides. If the disk shows info on the label on one side ONLY, then it MIGHT have been used as a DS disk, say as drive B: on the 8512, esp if written B:, even if it's a CF2 disk.

Geoff
Click to expand...

Well, computer TRIED to access the extra 40-44 tracks but drive was making horrible noises as the head reached it's physical limit and then address error popped up. Most files are unfortunatelly messed up likely because of that... Disks are like you said labelled separately for the side A and side B and separate lists of files pop up on each side - corresponding to the desciption of the label, so I'm pretty sure those are single sided disks. Question remains what about the extra tracks and why files start with contents cut in half (LOL it even says so in one of the file - of course unrelated) then there is some empty space and then a header of another file...
BTW I used XEXOR exclusively to copy the files. I can probably hook up the drive to Greaseweazle or the PC but I'm not sure if it would help in any way...

1729718346737.png

1729718149238.png
 
OK, sounds like the disks ARE single sided A: type disks, so no need to worry about that.

Regarding the data you see, this is because of the sector interleave, and is totally normal. The sectors are numbered 1 to 9, and the system reads the sectors by number, BUT the sectors are not placed on the disk in that order, and the image reflects that, so if you look at the image data raw then you see the files messed up. The interleave is (supposedly) to help performance. Even the PCW is fast enough that the interleave doesn't make THAT much difference. Not that I've noticed.

In the image, each track has a track header, and in the header you can see the sector numbers, and they are not in the correct order. I expect. If they show in the correct order, i.e. 1,2,3,4,5,6,7,8,9 - then there is no interleave. Will prob show 1,4,7,2,5,8,3,6,9 or something like. The idea is that the disk is spinning at a constant speed, and by the time the machine has finished reading one sector, then the next sector is just coming up to the head to be read. For the GOTEK, this is of course irrelevant as any sector is immed available, but the idea of the image is that it reflects how the real floppy is, and if you use an image to write back to real floppy then this is needed.

Your disks should NOT have anything in the 'extra' tracks. I mean the 'original' disks you have, that you need to image. The 'extra' disks MIGHT have been used before. The heads banging could damage the drive, so you should NOT let that happen (too much).

If you have created an image, you could copy me one and I'll check it out. Although the files LOOK messed up, they may be 100% correct.
 
GeoffB17 said:
OK, sounds like the disks ARE single sided A: type disks, so no need to worry about that.

Regarding the data you see, this is because of the sector interleave, and is totally normal. The sectors are numbered 1 to 9, and the system reads the sectors by number, BUT the sectors are not placed on the disk in that order, and the image reflects that, so if you look at the image data raw then you see the files messed up. The interleave is (supposedly) to help performance. Even the PCW is fast enough that the interleave doesn't make THAT much difference. Not that I've noticed.

In the image, each track has a track header, and in the header you can see the sector numbers, and they are not in the correct order. I expect. If they show in the correct order, i.e. 1,2,3,4,5,6,7,8,9 - then there is no interleave. Will prob show 1,4,7,2,5,8,3,6,9 or something like. The idea is that the disk is spinning at a constant speed, and by the time the machine has finished reading one sector, then the next sector is just coming up to the head to be read. For the GOTEK, this is of course irrelevant as any sector is immed available, but the idea of the image is that it reflects how the real floppy is, and if you use an image to write back to real floppy then this is needed.

Your disks should NOT have anything in the 'extra' tracks. I mean the 'original' disks you have, that you need to image. The 'extra' disks MIGHT have been used before. The heads banging could damage the drive, so you should NOT let that happen (too much).

If you have created an image, you could copy me one and I'll check it out. Although the files LOOK messed up, they may be 100% correct.
Click to expand...

These images which I mentioned previously were created the following way: empty image on the GOTEK, formated in Xexor 2.6, then files copied to the image from drive. Xexor tried to access the extra tracks, Xexor wouldn't find half of the files on the floppy.

Now when I'm using Discology it finds much more files and copies them without problem (unless there is a bad track on the disc but that's expected and so far I only found like 2 unreadable files). When copied and extracted files come out good! (mostly - see below).

Ideal way would be to make a sector copy from floppy to DSK image - ie by using Discology again - I tried and unfortunatelly DSK files come out unreadable.
Another better idea than coping individual files would probably be to use Greaseweazle but I'm not very fond of an idea connecting my only 3" drive to the PC as there are some (small) risks involved.

I attached DSK images with files copied under Xexor yesterday (just for fun - it's not correct, there is no need to waste time on it looking for a way to correct the interleave) and Discology. There should be 60 files in the Discology created image.

cj7hawk said:
How interesting - from 1988. A real glimpse into the past -

That's definitely a few sectors worth of text there.

Are you taking the files out in DSK format?

David.
Click to expand...

Yes, DSK format.

So my current workflow is as follows:

1) In Discology 5.1 I format gotek image with 44 tracks (perhaps regular 40 tracks would work too).

2) I copy files (files not discs - as it results in unreadable images) to the drive B (gotek image)

3) On the PC I use CPCDiskXP to extract files

4) I use ailink to convert them to DOC or whatever

This results in ~95% of the files to be converted correctly and readable on the PC.

There are some problems still:
CPCDiskXP won't extract few files from DSK (those are 0-byte sized GRP files but also some actual Locoscript files - usually 1-2 files are missing)
CPCDiskXP messes up content of GRP file with Locoscript file - again those are just like 1-2 files messed up
Other software to open images like CPCFS or DiskImageManager only sees and extracts around half of the files - it won't find any other files in the image. STRANGE.

Xexor 2.6 won't see all the files in the image created with Discology, these files won't show up using the cat command as well (it was like this when reading original floppies too!) - so only Discology is able to access all the files and write them correctly into DSK image other methods result in messed up files which include contents of the other half files that won't show up using cat, Xexor or whatever. I guess it may be related to the fact that the discs were created on the PCW under CP/M maybe...

Another idea to extract files would be to use CPCEmu and run Discology on it to extract the files it writted to DSK on the real hardware to the Tape (which is simply a directory) - but it won't do that - constantly tries to write the first file and basically does nothing.
 

Attachments

Last edited:
Both of those files appear corrupted to me as DSK files, but that might just be my reader. They appear to hold DSK formatting in binary when I look at the hex though. Sectors start with C, rather than 0 or something else.

It might be a type of Amstrad disk I haven't seen before.

HanJammer said:
Another idea to extract files would be to use CPCEmu and run Discology on it to extract the files it writted to DSK on the real hardware to the Tape (which is simply a directory) - but it won't do that - constantly tries to write the first file and basically does nothing.
Click to expand...

Well, here's the files I found on those two disks.

Were these what you were expecting? I was expecting both disks to be the same.
 

Attachments

In case you want to try the app I used, this is it - I'll include a binary and a source BASIC file that compiles under Freebasic in case you want to make your own binary.

To use, I do something like

mount DSKA0004.DSK A:
mount DSKA0005.DSK B:
mount DSKA0006.DSK C:
then I export the files such as;

A:
LPUT *.*

when done, type exit.
Then all the files are in the same directory from which you ran the binary, so it's a good idea to put it into it's own directory before running it.


You can also do stuff like

type <filename>
dump <filename>
dir
copy A:file B:file

etc.

Typing ? and enter will show the help menu, but you need to expand the CMD window to 1080P to see it all. If you check the Github link, the instructions are more readable there.

David
 

Attachments

cj7hawk said:
Both of those files appear corrupted to me as DSK files, but that might just be my reader. They appear to hold DSK formatting in binary when I look at the hex though. Sectors start with C, rather than 0 or something else.

It might be a type of Amstrad disk I haven't seen before.



Well, here's the files I found on those two disks.

Were these what you were expecting? I was expecting both disks to be the same.
Click to expand...
Like I said while the source floppy was the same - both images are not. First was formatted with Xexor 2.6 and I copied files with Xexor as well. Xexor just like AMSDOS (cat), CP/M and other tools I tried could access only half files on the original floppy (and instead messed up these files incorporating other half of the files in them). Second was formatted with Discology 5.1 and files were copied with Discology as well. Discology sees all of the files stored on the floppy and most of them (95%) comes out good when "unpacked" with CPCDiskXP.

Like I said before - I had to copy individual files - both Xexor and Discology wouldn't make sector (disc to disc) copies of the floppy - Xex would throw and error and Disco would make a corrupt unreadable image.

Files you sent in the DDISK.zip are EXACTLY what I expected - your tool did better job than the CPCDiskXP. Thanks for the tool! I will try to use it with the rest of the images.
 
cj7hawk said:
In case you want to try the app I used, this is it - I'll include a binary and a source BASIC file that compiles under Freebasic in case you want to make your own binary.

To use, I do something like

mount DSKA0004.DSK A:
mount DSKA0005.DSK B:
mount DSKA0006.DSK C:
then I export the files such as;

A:
LPUT *.*

when done, type exit.
Then all the files are in the same directory from which you ran the binary, so it's a good idea to put it into it's own directory before running it.


You can also do stuff like

type <filename>
dump <filename>
dir
copy A:file B:file

etc.

Typing ? and enter will show the help menu, but you need to expand the CMD window to 1080P to see it all. If you check the Github link, the instructions are more readable there.

David
Click to expand...
Does seem to work flawlessly to me. Much better than CPCDiskXP in my opinion. Generates some 0-sized files (not only grp files but also those supposed to be Locoscript files) but I guess it's related to the source disks and maybe the problem related to additional tracks beyond 40 being used which my drive simply won't read (although Discology didn't even tried to access them, unlike the Xexor).
 
Had a look at the two images (noted that this no longer matters) just for info.

These are CPC data Only formats, hence the C1 to C9 sector numbers. This is normal/correct for such CPC disks.

These images will load into LocoScript in the Joyce emulator, and a dir will show, but for 31 files ONLY, which I understand is incomplete. BUT try to load indiv files within Loco and get error, not valid filem even where file data starts JOY..

If I load the images within CP/M using Joyce emulator, again image is accepted, and a dir works OK, but shows 31 files ONLY again, and when I use DUMP to view the file the data is wrong, i.e. one file merges into another, or one file terminates incorrectly.

I'm sure this is connected with invalid sector interleave (which can affect the directory as well - 31 files suggests that 2 sectors ONLY of dir are being seen).

Note, the interleave shown on the disks is 1,6,2,7,3,8,4,9,5

Need to look at the actual data in the sectors in the image to see if the REAL interleave of the data matches the interleave of the format. It might not. But why? Mixing different machines, that might be expecting different interleaves?

Geoff
 
I've had a close look at the image, and allowing for the interleave the image seems to be correct. Certainly as far as Tr 0 and 1 are concerned. The 31 files showing are correct, there are 4 dir sectors, the first is full, the second had one empty space, and the other two are clearly visible and empty. The first file starts at the next alloc, which is sectors 5 and 6, sector 5 is the last sector on the track as per the interleave, and this sector shows the JOY.. for the start of the doc. The second file in the dir should start at sector 17 which is in Tr 1 which by the interleave should be the 8th sector, this also shows the JOY.. header for top of file.

So loco and CP/M in Joyce are reading the disk, initially, correctly (the dir is on Track 0, as opposed to Tr 1 for the normal PCW disk) but then is not reading the indiv file correctly. Why? Regardless of other things, I'm interested to sort this!

Geoff
 
HanJammer said:
Files you sent in the DDISK.zip are EXACTLY what I expected - your tool did better job than the CPCDiskXP. Thanks for the tool! I will try to use it with the rest of the images.
Click to expand...

The program is buggy, but the files it finds should be correct. They are all name.date format, and all 11 characters, so the filename bug works to your advantage here which I didn't expect. I'm assuming that's a CPC way of doing things. I got a CPC recently, but haven't had a very close look at it's data format and haven't set up a Gotek for it yet.

GeoffB17 said:
I've had a close look at the image, and allowing for the interleave the image seems to be correct. Certainly as far as Tr 0 and 1 are concerned. The 31 files showing are correct, there are 4 dir sectors, the first is full, the second had one empty space, and the other two are clearly visible and empty. The first file starts at the next alloc, which is sectors 5 and 6, sector 5 is the last sector on the track as per the interleave, and this sector shows the JOY.. for the start of the doc. The second file in the dir should start at sector 17 which is in Tr 1 which by the interleave should be the 8th sector, this also shows the JOY.. header for top of file.

So loco and CP/M in Joyce are reading the disk, initially, correctly (the dir is on Track 0, as opposed to Tr 1 for the normal PCW disk) but then is not reading the indiv file correctly. Why? Regardless of other things, I'm interested to sort this!

Geoff
Click to expand...

That's a good question. I wrote my app to decode the same thing, and once I masked for 63 sectors max ( I didn't know why I saw C in front of all the sectors ) it started reading the disks OK. One of the bugs in my program is that it assumes the disk format is valid, but because of this, can overwrite memory if the disk data is invalid. Hence the 6S (6-bit sector) suffix on the version I poseted for @HanJammer.

I can copy the files back to a Joyce type disk easily enough though... Which may make it easier to try out.

PCW-9512 style disk image attached with the D-Disk contents included.
 

Attachments

Mixing re CPC formats and PCW formats may be problematic.

The PCWs can supposedly detect CPC formats, but not sure how they do it, and how reliable the process is. Important thing, I believe, is that the PCW uses a 16 byte XDPB data item at the start of the first sector on the disk to determine the format of the disk, but the CPCs do not have this data (there is no space for it with the CPC Data format).

Here we have disks supposedly originally from a PCW (assumed), which should have a PCW format and a PCW type disk header, disk maybe then used on a CPC (interpreting the format as what?). Any chance any of the disks might have been written to on the CPC?

Geoff
 
Maybe some good news for you.

Trying to access the image files within Joyce is still problematic. But I was trying the 'X' image, and in fact both the images I'd ended up with were the same 'X' imagem due to me messing up filenames when unzipping.

I've now redone the unzip, and I've now got two different files.

When I try the 'D' image, Joyce & Locoscript still gives the error message 'Not a Loco File' and refuses to load the file, I'm still trying to work out why.. Looking at the hex data, the files seem OK. I've got John Elliott's notes on Loco File format, and seems OK.

Used the same image Joyce & CP/M, and now DUMP seems to be giving clean display of file contents, this looks better than the result with the ''X' file.

So, I've exported a couple of the document files from the image, and got them onto a CP/M disk. I've got my PCW 8256 booted into Loco 1.2 (The documents by the way are certainly Loco 1), and !!!!!! YES, the documents now load correctly into Loco, and all normal functions seem to be available.

Geoff
 
GeoffB17 said:
Maybe some good news for you.

Trying to access the image files within Joyce is still problematic. But I was trying the 'X' image, and in fact both the images I'd ended up with were the same 'X' imagem due to me messing up filenames when unzipping.

I've now redone the unzip, and I've now got two different files.

When I try the 'D' image, Joyce & Locoscript still gives the error message 'Not a Loco File' and refuses to load the file, I'm still trying to work out why.. Looking at the hex data, the files seem OK. I've got John Elliott's notes on Loco File format, and seems OK.

Used the same image Joyce & CP/M, and now DUMP seems to be giving clean display of file contents, this looks better than the result with the ''X' file.

So, I've exported a couple of the document files from the image, and got them onto a CP/M disk. I've got my PCW 8256 booted into Loco 1.2 (The documents by the way are certainly Loco 1), and !!!!!! YES, the documents now load correctly into Loco, and all normal functions seem to be available.

Geoff
Click to expand...

I did remake the D-Disk into a 9512 style disk image and linked it above - did any of the files on the 9512 disk image I sent through work OK? My joyce emulator died before I could try it.

It makes me wonder if there was ever a version of Locoscript that ran on the CPC?
 
I archived what I could from the disks. They will likely appear in the Digital Archive of the KARTA foundation https://karta.org.pl/archiwum some time later.

I also had to copy some individual files again to another empty disk and then unpack them with cpmtool as they came out wrong in the first time (cpmtool unpacked 0-sized files while CPCDiskXP messed up the contents with something that looked like a table of directory entries. But copying them into empty disk - they came out OK this time.

Another observation is that Panasonic EBF-CF2 were all read without problems although some of these disks date back to the second half of the 80s, while Maxell CF2 disks from the early 90s pretty much all are partially unreadable (maybe creating raw images using Greaseweazle would allow to partially save the contents of the files, but I'm not going to do that). Weak!

BTW - I didn't had much experience with Amstrad CPC to date, and I'm amazed how fast this computer is, especially that it uses fairly complex GUI driven software like Discology. I mean it's at least as fast as Macintosh Plus I have. I love it!
 
Hello,

I remember seeing the attachment re the 9512 type image, but I didn't download it, so not looked at that. I have actual 9512 real disks anyway, and contents from 9512 system disks, so not a lot of point re my interests, but as you ask if the files are OK, I'll get the image and check it out. No problem.

I'm almost certain there never was a version of LocoScript for any CPC. The software was heavily reliant on the facilities offered by the PCW. Especially the RAM available, and the screen size. The dedicated printer (with the special chars) was also important.

I'm still concerned re problems with the images, wondering why? I'd like to explain this. The images appear to be OK, looking at the raw hex of the images. But the images do not work properly, in prob quite small reasons. Maybe just a small error in the various data that defines the disk format. Maybe some small thing re how the CPC handles PCW disks/images. The PCW is supposed to handle CPC disks/images, but vice-versa was never intended!

I've very rarely had any problems with either Panasonic CF2s, or Maxel. Both have been good for me. The Panasonic ones also come labelled as Amsoft, also Hitachi, and I've seen some with no specific brand but clearly the Panasonic manufacture. But re your comment, my Maxel disks prob all from 80s, and quality prop did go downhill later. That's also when cheap copies of the disks started to appear, most of them were REALLY bad.

I've never had or used any of the CPCs, so I cannot comment on that!

Geoff
 
Oops - realised that the above message replies to two different messages from two different people! I trust each can spot their part!

I've now checked the 9512 disk image, loading the disk into Joyce. Unlike the previous images tried, this time I was able to access the files tried fine within LocoScript.

If this disk/image was created completely on a PCW, with no CPC involved, maybe this is why? Maybe a (possibly tiny) confusion with the CPC regarding CPC and PCW disk format.

Geoff
 
You must log in or register to reply here.
Back
Top