Support for Apricot floppies.

[GWHAYWOOD]

David,

Thank you for your very quick response to my 3 Sept. query on your Website about Apricot floppies, and apologies for the delay in replying.

Since then I've made a little more progress. I'm beginning to get a grip on using the Fluxengine software with the Greaseweazle. Everything so far is at the command line, I haven't built the GUI.

The drive used in the Apricot Xi machines which we used here in the 1980s and 1990s was made by Sony, I've found the service manual[*] for it, and that indicates that the drive at least is 80 track. My confidence that what I read about the floppies being 70 track is further eroded, but time may yet tell. I have at least three examples of this drive but I think none of them has worked reliably for three decades or more.

For the moment I'm using a 2000-era half-height 3.5" drive with the Greaseweazle. As yet I haven't risked any of the old Xi floppies in any drive, but a scratch sample, which may well have been written by an IBM PC clone and not the Xi, and which I can bear to lose, did read mostly OK using this setup - four bad blocks at the first attempt. Now I need to gain some famimliarity with it all to see if I can e.g. improve the read results by tweaking things.

It's good to know that you'd like to add support for Apricot floppies. Can I do anything for you or provide anything to you which will help? Will it just be a matter of creating a file with some parameters?

Thanks once again for your attention.

Cheers, Ged.

[*] http://www.bitsavers.org/pdf/sony/floppy/Sony_OA-D32_Microfloppy_Service_Nov83.pdf The Xi used the double-sided version of this drive.

PS: My browser (Palemoon) doesn't seem to play well with Github. I don't know why - other people seem to manage with the same browser. It might be something to do with the transport and I'm going to try forcing IPv4 when I get a minute. I'm also rather unfamiliar with both Github and Markdown. It's possible that this will cause issues. I work a lot better with email, especially if it involves any code.

[davidgiven]

The docs look like the Apricot is using a standard IBM scheme format, so this should just be a matter of creating an appropriate configuration file. See for example: https://github.com/davidgiven/fluxengine/blob/master/src/formats/psos.textpb You can use the name of a config file instead of a profile name on the command line to read the config from there rather than using one of the built-in ones.

I found this disk description: http://actapricot.org/disks/aprid5ks.htm#apr00031.dsk It claims nine sectors, single sided, 70 tracks per disk. This means that you could probably read a disk with the 720_96 ibm profile, although it'll read a lot of garbage (the second side if this is a single sided disk, tracks above 70). Try reading your scratch disk with --decoder.retries=0 and --copy-flux-to=something.flux. That will prevent retries on non-understood sections and produce an output flux file which can be used for further analysis without needing to reread the disk.

(Re github: you should be getting an email notification for my message. Replying directly to it should append a comment --- it's supposed to work like a mailing list.)

[GWHAYWOOD]

David,

On Wed, 6 Sep 2023, David Given wrote:

The docs look like the Apricot is using a standard IBM scheme format, so this should just be a matter of creating an appropriate configuration file. See for example: https://github.com/davidgiven/fluxengine/blob/master/src/formats/psos.textpb

Unfortunately this is where my browser and github don't get on. All I see at that link is a blank page. It happens a lot with github.

You can use the name of a config file instead of a profile name on the command line to read the config from there rather than using one of the built-in ones.

I'm still a bit woolly on configs and specifying them in a command but I'll get there.

http://actapricot.org/disks/aprid5ks.htm#apr00031.dsk claims nine sectors, single sided, 70 tracks per disk.

About two-thirds of the discs on that page say 70 track, the rest 80. I'm beginning to wonder if they didn't change from 70 to 80 somewhere along the line.

... you could probably read a disk with the 720_96 ibm profile, although it'll read a lot of garbage ...

When I used that profile with what I'm sure is an Apricot disc with files copied on the Apricot Xi around 1985 it seemed to read perfectly and it appeared to read all 80 tracks! The image produced is 737280 bytes (flux data about 10MBytes). The Linux 'file' utility recognizes the image only as 'data'. Of course I haven't been able to mount it, but it looks like good data. I'll nose around to see what I can find out about the filesystem that's supposed to be on there. Maybe there's a kernel module I can load or something.

Thanks, Ged.

[davidgiven]

The docs I've found says the Xi uses a normal FAT filesystem; FluxEngine supports that natively, so with the right settings you should be able to read and write files directly. Could you send me the flux file somehow (assuming there's nothing confidential in it, of course)? Dropbox or Google Drive or the like is preferable over email; Gmail thinks flux files are dangerous and removes them.

[GWHAYWOOD]

David,

On Wed, 6 Sep 2023, David Given wrote:

The docs I've found says the Xi uses a normal FAT filesystem;

It isn't exactly like the one used by the IBM PC - different boot sector, missing 'JMP' instruction etc., layout, see for example

https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Exceptions

FluxEngine supports that natively, so with the right settings you should be able to read and write files directly.

That would be great!

Could you send me the flux file somehow (assuming there's nothing confidential in it, of course)? Dropbox or Google Drive or the like ...

There's nothing confidential (and it would be 37 years old. :)

Try

http://www.jubileegroup.co.uk/misc/051.tgz

This disc was written in February 1986 and hasn't been touched since. It seemed to read fine, with absolutely no errors. Sony brand, IIRC we paid sixty pounds for a box of ten at the time although you could get cheaper brands.

Have fun!

73, Ged.

[davidgiven]

I bullied minifat into reading the filesystem. Thank you for the link; it'd never have occurred to me to get that kind of technical detail from Wikipedia...

I see three files:

  READTHIS.DVS       128 A    
  ROOT.ARC        489516 A    
  DVS.ARC         105341 A    

The first one contains:

00000000   54 68 65 20  61 72 63 68  69 76 65 20  44 56 53 2E  The archive DVS.
00000010   41 52 43 20  63 6F 6E 74  61 69 6E 73  20 66 69 6C  ARC contains fil
00000020   65 73 20 77  68 69 63 68  20 77 65 72  65 20 69 6E  es which were in
00000030   20 61 0D 0A  73 75 62 64  69 72 65 63  74 6F 72 79   a..subdirectory
00000040   20 63 61 6C  6C 65 64 20  5C 44 56 53  2E 0D 0A 1A   called \DVS....
00000050   1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  ................
00000060   1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  ................
00000070   1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  1A 1A 1A 1A  ................

So that all looks promising.

The disk itself is genuinely 720kB, with 80 tracks and double sided. I would call this standard IBM PC format but with a non-standard file system.

I've pushed the changes to the apricot branch if you want to try them. You should be able to use ibm --720_96. If you have any 70-track disks, that will need a custom profile.

BTW, before you try any precious disks in a drive, make sure to do a visual inspection by rotating the cookie in the sleeve and looking for mould or other marks on the disk surface. It sounds like your disks were stored well but I've heard horror stories. Get a piece of grit stuck on a the disk head and the drive will wreck every disk put in it!

[davidgiven]

(Addendum: it'll need more work to allow minifat to actually create these filesystems. I don't know what parts of the header are necessary for the Apricot to detect it as a valid filesystem, but I gather you don't actually have any Apricot hardware?)

[GWHAYWOOD]

On Wed, 6 Sep 2023, David Given wrote:

I bullied minifat into reading the filesystem. Thank you for the link; it'd never have occurred to me to get that kind of technical detail from Wikipedia...

Well done! And I'm glad to be able to help in whatever small way. My wife says that my search skills are better than average, but in truth I think I'm just not as impatient as she, and I'm prepared to fumble around for longer.

... READTHIS.DVS 128 A ROOT.ARC 489516 A DVS.ARC 105341 A ... So that all looks promising.

That looks exactly right.

The disk itself is genuinely 720kB, with 80 tracks and double sided. I would call this standard IBM PC format but with a non-standard file system.

That sounds like what I'd have expected. Until starting on this, hm, journey I'd never thought that the numbers of tracks might not be the same as the drive's specification. Now, in view of how many 70-track images seem to be around, I wonder if it was a different drive in the early models of the machine and they upgraded, or something like that. As yet I've seen nothing written about it. There's still one itch I need to scratch, in that everything I've seen written claims that the Apricot PC and Xi ran the CPU at 5MHz; yet for several decades I've had it in my mind that the Xi machines which we used ran at 6MHz. It was one of the reasons I always thought the Apricot beat the PC/XT on performance. It all sounds silly now...

I've pushed the changes to the apricot branch if you want to try them.

Thanks! I've grabbed the code, I hope to get to that later today.

You should be able to use ibm --720_96. If you have any 70-track disks, that will need a custom profile.

I don't know if I have any 70-track discs or not, I hope to find out. There are several hundreds of them, but most seem to be 1.44MByte, of much later manufacture than those we used to use in the Apricots.

BTW, before you try any precious disks in a drive, make sure to do a visual inspection by rotating the cookie in the sleeve and looking for mould or other marks on the disk surface. It sounds like your disks were stored well but I've heard horror stories. Get a piece of grit stuck on a the disk head and the drive will wreck every disk put in it!

Ouch! Then I'll inspect them more carefully, I haven't been doing. But you're right, these discs have been stored well. Am I right in thinking that the drive interface is much the same for more or less any 3.5" drive, and that the track spacing is controlled by stepper motors with one track per step? Are the track-to-track spacings the same on all 3.5" floppy discs? I'm just thinking about using a new (well, newer) 3.5" drive (e.g. Mitsumi) in the Apricot instead of one of the old Sony drives if the old drives turn out to be unrecoverable.

(Addendum: it'll need more work to allow minifat to actually create these filesystems. I don't know what parts of the header are necessary for the Apricot to detect it as a valid filesystem, but I gather you don't actually have any Apricot hardware?)

On the contrary, I have four Apricot Xi machines but AFAIK at present none of them has a working floppy drive. One drive is missing, and I don't know why; two drives I found on a shelf in our warehouse are on the bench - one has the screws removed from its EMI cover; one drive is in a machine but I haven't dared put a disk in it. At least one of the machines will boot, but when I switched it on a few weeks ago the second thing that happened after it booted was that there was a 'pop' from inside the system unit and smoke came out of it. Obviously then I switched it off. I haven't risked switching it on again since that experience, but reading around I gather it's a common issue with the component which is supposed to suppress mains-borne interference, and the machine can function perfectly well without it. When I'm feeling brave enough I'll give it another go. Before doing that I hope to get at least one of the floppy drives working on the bench. I've promised one of the Xis to a guy in Newcastle who wants to refurbish it for a computing museum up there, and there are people interested in others, but I've been too pressed to spend much time on them. There were bits all over the place, I've collected most of what I could find into four heaps of parts but there's still some sorting out to do. I've found something like seven or eight tape drives and a variety of software to operate them, plus about sixty of our 1990s-era backup tapes. Reading about things like Greaseweazle I've seen references to people wanting to do flux-twiddling work on tapes too. Have you thought about that?

Well, this has been a blast so far! Thanks again.

Ged.

[GWHAYWOOD]

David,

I've built the Apricot version of fluxengine and then read a scratch disc (number 058) using

$ .../fluxengine read ibm --720_96 --copy-flux-to 058.flux -o 058.img

which produced these files:

-rw-r--r-- 1 ged ged 12290832 Sep 7 12:15 058.flux -rw-r--r-- 1 ged ged 737280 Sep 7 12:15 058.img

There are four bad sectors on this disc, and to my eye the results of the read are more or less indistinguishable from those given by the master branch which also showed four bad sectors:

8<---------------------------------------------------------------------- Tracks -> 1 2 3 4 5 6 7 H.SS 01234567890123456789012345678901234567890123456789012345678901234567890123456789

0. 1 ................................................................................
1. 2 ................................................................................
2. 3 ................................................................................
3. 4 ................................................................................
4. 5 ................................................................................
5. 6 ................................................................................
6. 7 ................................................................................
7. 8 ................................................................................
8. 9 ................................................................................
9. 1 ................................................................................
10. 2 ................................................................................
11. 3 ................................................................................
12. 4 .........................................................................BBB....
13. 5 ................................................................................
14. 6 B...............................................................................
15. 7 ................................................................................
16. 8 ................................................................................
17. 9 ................................................................................ Good sectors: 1436/1440 (99%) Missing sectors: 0/1440 (0%) Bad sectors: 4/1440 (0%) IMG: wrote 80 tracks, 2 sides, 720 kB total to 058.img 8<----------------------------------------------------------------------

I'm interested to know what tweaks there might be to perhaps recover any data in bad sectors, but it isn't a priority for me right now. I'd first really like to read more, so I can understand the configuration a lot better. At present it's all very foggy.

Is there anything I can do with the Apricot branch and maybe the Apricot discs which will help you? I can e.g. read a few discs and let you have the flux/image files etc. if you wish.

Thanks for your tremendous help.

Ged.

[GWHAYWOOD]

Hmmm, Github seems to have bowdlerized my last. Maybe you'll get the rest of the message in the email.

[davidgiven]

Oops, I forgot how to tell you how to use the filesystem code. Either use the GUI, or:

fluxengine ls ibm --720_96 -f drive:0
fluxengine getfile ibm --720_96 -f drive:0 -p FILENAME

Replace -f drive:0 with -f something.flux or -i something.img if you want to read from a flux file or image instead of a physical disk.

[GWHAYWOOD]

On Thu, 7 Sep 2023, David Given wrote:

Oops, I forgot how to tell you how to use the filesystem code.

That will help. :)

Either use the GUI,

Didn't build it. Incidentally for both the Apricot branch and the master branch, to get it past fussy gcc I had to comment out 'const' at line 96 of lib/sector.h.

or:

fluxengine ls ibm --720_96 -f drive:0
fluxengine getfile ibm --720_96 -f drive:0 -p FILENAME

Seems to work fine! Let me try some markdown...

***@***.***:~/ged/FLOPPIES $ ../fluxengine ls ibm --720_96 -i 051/051.img
       OPTION: 720kB 5.25" 80-track 9-sector DSDD
       IMG: read 80 tracks, 2 sides, 720 kB total from 051/051.img
   READTHIS.DVS       128 A
   ROOT.ARC        489516 A
   DVS.ARC         105341 A 
(3 files, 594985 bytes)
***@***.***:~/ged/FLOPPIES $ ../fluxengine ls ibm --720_96 -i 058/058.img
       OPTION: 720kB 5.25" 80-track 9-sector DSDD
       IMG: read 80 tracks, 2 sides, 720 kB total from 058/058.img
   DOODLE.ZIP    695616 A 
(1 files, 695616 bytes)
***@***.***:~/ged/FLOPPIES $ ../fluxengine ls ibm --720_96 -i 070/070.img
       OPTION: 720kB 5.25" 80-track 9-sector DSDD
       IMG: read 80 tracks, 2 sides, 720 kB total from 070/070.img
   NEWMLL.ARC    116208 A
   OLDMLL.ARC    286550 A
   README           174 A 
(3 files, 402932 bytes)
***@***.***:~/ged/FLOPPIES $ ../fluxengine ls ibm --720_96 -i 111/111.img
       OPTION: 720kB 5.25" 80-track 9-sector DSDD
       IMG: read 80 tracks, 2 sides, 720 kB total from 111/111.img
   IO.SYS           33430 RHSA
   MSDOS.SYS        37394 RHSA
   COMMAND.COM      47845 A 
D DOS                  0
   LLPRO.EXE       222370 A
   LLPRO.CFG          283 A 
D EXT                  0
   AUTOEXEC.GED       427 A
   CONFIG.GED         606 A
   CONFIG.BAK         309 A
   AUTOEXEC.BAK       697 A
   AUTOEXEC.BAT       145 A
   CONFIG.SYS         212 A 
(13 files, 343718 bytes)
***@***.***:~/ged/FLOPPIES $ hexdump -f ~/format_64a.spec_for_hexdump 051/051.img | head
000000 565220312e332e320100000000000002090050000000020101000000000000000000000000000000120000000000000000000000000000000000000000000000 VR 1.3.2..........P.............................................
000040 00000000000000000000000000000000000202010002b000a005fe03000200000000000000000000000000000000000000000000000000000000000000000000 ................................................................
000080 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ................................................................
*
000100 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ................................................................
*
000200 feffffff4f0005600007800009a0000bc0000de0000f000111200113400115600117800119a0011bc0011de0011f000221200223400225600227800229a0022b ....O..`................. ..@..`................! .***@***.***%`.'..)..+
000240 c0022de0022f000331200333400335600337800339a0033bc0033de0033f000441200443400445600447800449a0044bc0044de0044f00055120055340055560 ..-../..1 .***@***.***`.7..9..;..=..?..A .***@***.***`.G..I..K..M..O..Q .***@***.***`
000280 0557800559a0055bc0055de0055f000661200663400665600667800669a0066bc0066de0066f000771200773400775600777800779a0077bc0077de0077f0008 .W..Y..[..].._..a .***@***.***`.g..i..k..m..o..q .***@***.***`.w..y..{..}.....
0002c0 81200883400885600887800889a0088bc0088de0088f000991200993400995600997800999a0099bc0099de0099f000aa1200aa3400aa5600aa7800aa9a00aab . ..@..`................. ..@..`................. ..@..`........
***@***.***:~/ged/FLOPPIES $ hexdump -f ~/format_64a.spec_for_hexdump 058/058.img | head
000000 eb289049424d20504e43490002020100027000a005f90300090002000000000000000000000000000000fa33c08ed0bcf07bfbb8c0078ed8be5c009090fcac0a .(.IBM PNCI......p.........................3.....{.......\......
000040 c0740b56b40ebb0700cd105eebf032e4cd16b40fcd1032e4cd10cd190d0a0d0a0d0a0d0a0d0a0d0a0d0a0d0a2020202054686973206469736b206973206e6f74 .t.V.......^..2.......2.....................    This disk is not
000080 20626f6f7461626c650d0a0d0a20496620796f75207769736820746f206d616b6520697420626f6f7461626c652c0d0a72756e2074686520444f532070726f67  bootable.... If you wish to make it bootable,..run the DOS prog
0000c0 72616d20535953206166746572207468650d0a202020202073797374656d20686173206265656e206c6f616465640d0a0d0a506c6561736520696e7365727420 ram SYS after the..     system has been loaded....Please insert 
000100 6120444f53206469736b6574746520696e746f0d0a2074686520647269766520616e6420737472696b6520616e79206b65792e2e2e0000000000000000000000 a DOS diskette into.. the drive and strike any key..............
000140 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ................................................................
*
0001c0 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055aa ..............................................................U.
000200 f9fffff74f0005600007800009a0000bc0000de0000f000111200113400115600117800119a0011bc0011de0011f000221200223400225600227800229a0022b ....O..`................. ..@..`................! .***@***.***%`.'..)..+
000240 c0022de0022f000331200333400335600337800339a0033bc0033de0033f000441200443400445600447800449a0044bc0044de0044f00055120055340055560 ..-../..1 .***@***.***`.7..9..;..=..?..A .***@***.***`.G..I..K..M..O..Q .***@***.***`
***@***.***:~/ged/FLOPPIES $ hexdump -f ~/format_64a.spec_for_hexdump 070/070.img | head
000000 565220312e332e320100000000000002090050000000020101000000000000000000000000000000120000000000000000000000000000000000000000000000 VR 1.3.2..........P.............................................
000040 00000000000000000000000000000000000202010002b000a005fe03000200000000000000000000000000000000000000000000000000000000000000000000 ................................................................
000080 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ................................................................
*
000100 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ................................................................
*
000200 feffff03400005600007800009a0000bc0000de0000f000111200113400115600117800119a0011bc0011de0011f000221200223400225600227800229a0022b ....@..`................. ..@..`................! .***@***.***%`.'..)..+
000240 c0022de0022f000331200333400335600337800339a0033bc0033de0033f000441200443400445600447800449a0044bc0044de0044f00055120055340055560 ..-../..1 .***@***.***`.7..9..;..=..?..A .***@***.***`.G..I..K..M..O..Q .***@***.***`
000280 0557800559a0055bc0055de0055f000661200663400665600667800669a0066bc0066de0066f000771200773400775600777800779a0077bc0077de0077f0008 .W..Y..[..].._..a .***@***.***`.g..i..k..m..o..q .***@***.***`.w..y..{..}.....
0002c0 81200883400885600887800889a0088bc0088de0088f000991200993400995600997800999a0099bc0099de0099f000aa1200aa3400aa5600aa7800aa9a00aab . ..@..`................. ..@..`................. ..@..`........
***@***.***:~/ged/FLOPPIES $ hexdump -f ~/format_64a.spec_for_hexdump 111/111.img | head
000000 eb3c9029374c405f4948430002020100027000a005f90300090002000000000000000000000029ed15003f3134304d422053435349204641543136202020fa33 .<.)7L@_IHC......p....................)...?140MB SCSI FAT16   .3
000040 c08ed0bc007c1607bb780036c5371e561653bf3e7cb90b00fcf3a4061fc645fe0f8b0e187c884df9894702c7073e7cfbcd13727933c03906137c74088b0e137c .....|...x.6.7.V.S.>|.........E.....|.M..G...>|...ry3.9..|t....|
000080 890e207ca0107cf726167c03061c7c13161e7c03060e7c83d200a3507c8916527ca3497c89164b7cb82000f726117c8b1e0b7c03c348f7f30106497c83164b7c .. |..|.&.|...|...|...|....P|..R|.I|..K|. ..&.|...|..H....I|..K|
0000c0 00bb00058b16527ca1507ce89200721db001e8ac0072168bfbb90b00bee67df3a6750a8d7f20b90b00f3a67418be9e7de85f0033c0cd165e1f8f048f4402cd19 ......R|.P|...r......r........}..u... .....t...}._.3...^....D...
000100 585858ebe88b471a48488a1e0d7c32fff7e30306497c13164b7cbb0007b90300505251e83a0072d8b001e85400595a5872bb05010083d200031e0b7ce2e28a2e XXX...G.HH...|2.....I|..K|......PRQ.:.r....T.YZXr..........|....
000140 157c8a16247c8b1e497ca14b7cea00007000ac0ac07429b40ebb0700cd10ebf23b16187c7319f736187cfec288164f7c33d2f7361a7c8816257ca34d7cf8c3f9 .|..$|..I|.K|...p....t).........;..|s..6.|....O|3..6.|..%|.M|...
000180 c3b4028b164d7cb106d2e60a364f7c8bca86e98a16247c8a36257ccd13c30d0a4e6f6e2d53797374656d206469736b206f72206469736b206572726f720d0a52 .....M|.....6O|......$|.6%|.....Non-System disk or disk error..R
0001c0 65706c61636520616e6420707265737320616e79206b6579207768656e2072656164790d0a00494f2020202020205359534d53444f53202020535953000055aa eplace and press any key when ready...IO      SYSMSDOS   SYS..U.
000200 f9ffff03400005600007800009a0000bc0000de0000f000111200113400115600117800119a0011bc0011de0011f0002212002ff4f0225600227800229a0022b ....@..`................. ..@..`................! ..O.%`.'..)..+
000240 c0022de0022f000331200333400335600337800339a0033bc0033de0033f000441200443400445600447f0ff49a0044bc0044de0044f00055120055340055560 ..-../..1 .***@***.***`.7..9..;..=..?..A .***@***.***`.G..I..K..M..O..Q .***@***.***`
***@***.***:~/ged/FLOPPIES $ 

Discs numbered 051 and 070 are Apricot format, 058 is PC format, not quite sure about 111 although its label claims IBM format and like 058 it mounts under Linux OK. 051 and 070 don't.

Any chance of getting the timestamps with the 'ls' command?

Ged.

[GWHAYWOOD]

Looking at this page in my browser, my attempt at using markdown was an unqualified disaster.

:(

[davidgiven]

Fiddling with it in the editor shows that if you reply by email you don't get markdown!

[GWHAYWOOD]

On Fri, 8 Sep 2023, David Given wrote:

Fiddling with it in the editor shows that if you reply by email you don't get markdown!

Well that's just great...

[GWHAYWOOD]

FYI: in http://cowlark.com/fluxengine/doc/driveresponse.html

I count two instances of "left" which I think should say "right". For reference, both are near the word "smear" and refer to a smear of rainbow colours on a graph.

[GWHAYWOOD]

FYI: in http://cowlark.com/fluxengine/doc/using.html

the text "for obvious results" should probably read "for obvious reasons".

[GWHAYWOOD]

A few days ago I came across 'apriboot'. I can't now remember exactly how I found it but I'm glad I did!

https://manpages.ubuntu.com/manpages/jammy/en/man1/apriboot.1.html

I've tried it on a couple of Apricot images and it seems to work fine; after modifying an image using

apriboot disc.img

(which modifies disc.img in place) I can mount the modified image under linux using 'mount' and treat it just as if it had been written on an IBM-compatible PC.

The apriboot source might might tell you all you need to know about the Apricot boot sectors.

HTH

Ged.

[davidgiven]

I'm sorry, I've been working on other things.

Looking at you calling fluxengine ls above, it appears that the filesystem is being corectly parsed. Do the contents of the files look good too? You should be able to get things like the mtime of the files using fluxengine getfileinfo.

If they look good, then I can probably consider this working, so will update the docs and merge the changes into master.

[GWHAYWOOD]

I don't think we're quite out of the woods yet.

I've found an Apricot disc for which 'fluxengine ls' and 'fluxengine getfileinfo' do not work.

If I convert the image to an IBM image using 'apriboot' it reads fine:

8<-------------------------------------------------------------------------------------------

~/FLOPPIES/3.5/DOUBLE_DENSITY/DOS_APRICOT/PERFECT_READS/040 $ fluxengine ls ibm --720_96 -i 040.img OPTION: 720kB 5.25" 80-track 9-sector DSDD IMG: read 80 tracks, 2 sides, 720 kB total from 040.img Error: Invalid filesystem ~/FLOPPIES/3.5/DOUBLE_DENSITY/DOS_APRICOT/PERFECT_READS/040 $ cp 040.img 040.IBM.img ~/FLOPPIES/3.5/DOUBLE_DENSITY/DOS_APRICOT/PERFECT_READS/040 $ apriboot 040.IBM.img 040.IBM.img: Bootsector converted to PCDOS format ~/FLOPPIES/3.5/DOUBLE_DENSITY/DOS_APRICOT/PERFECT_READS/040 $ fluxengine ls ibm --720_96 -i 040.IBM.img OPTION: 720kB 5.25" 80-track 9-sector DSDD IMG: read 80 tracks, 2 sides, 720 kB total from 040.IBM.img COMMAND.COM 16256 A
CONFIG.BAK 128 A
DISKCOPY.COM 1536 A
FONT.SYS 10240 HSA
GEDKEYS.KB 1024 A
HEADER.SYS 512 HSA
IO.SYS 46080 HSA
KEYTAB.SYS 1024 HSA
MSDOS.SYS 17408 HSA
NORTON.KB 1024 A
SWKEYS.KB 1024 A
... ... AUTOEXEC.BAK 41 A
AUTOEXEC.BAT 34 A
(18 files, 715498 bytes)

8<-------------------------------------------------------------------------------------------

I can't immediately let you have this image because it contains some confidential information in deleted sectors. The options are

1. I work on that before releasing it or

2. I find another image which behaves in the same way (a significantly larger selection is available now, I just have to look...:) or

3. Maybe the first few sectors of the image would be enough for you to work on - please let me know.

There's no rush as far as I'm concerned, I'm very busy too at the moment and 'apriboot' lets me do what I need to do for now albeit with a very slight inconvenience.

It's also possible that although the disc read perfectly it might not even read properly on an Apricot. I need to check, but I would need to do some soldering before I can test that to my satisfaction. If I find more Apricot images which give the same trouble that would tend to point to a fluxengine issue rather than a disc formatting issue but I think the only way to be really sure is to try the disc in a floppy drive in an Apricot.

[GWHAYWOOD]

It seems like the problem is in the first sector.

Some of the discs I'm reading have a version number in the first few bytes:

$ hx 036/036.img | head -n 1 000000565220312e332e32010000000000000209005000000002010100000000 \ 0000000000000000000000120000000000000000000000000000000000000000000000 \ VR 1.3.2..........P.............................................

Others don't have this version number:

$ hx 026/026.img | head -n 1 00000000000000000000000100000000000002090050000000020101001f00000 \ 05e000000800d2900000e1200000000000000ffff0000000000000000000000000000 \ ..................P...........^.....)...........................

It seems that those which do have the version number can be read by 'ls', and those which don't cannot.

[davidgiven]

That's the disk label, and should be ignored. The actual useful bits start further on --- there's a good reference here: https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html ...but that doesn't contain the Apricot changes.

There's clearly something going on here. Can you send me the boot sector, i.e. the first 512 bytes? There shouldn't be anything confidential there (unless there's some super secret boot loader).

[GWHAYWOOD]

Here are four boot sectors, two which fail (027 and 040) and two which don't (028 and 036).

http://www.jubileegroup.co.uk/misc/boot_sectors.tgz

[GWHAYWOOD]

I thought it may help if I included the boot sectors from the four images after treatment by 'apriboot':

http://www.jubileegroup.co.uk/misc/apriboot_sectors.tgz