Archiving my floppies: Am I doing this the right way?

[MVladimir]

On 4/2/2023 at 4:44 PM, CharlieChaplin said:

There are several sectorcopy programs that will show a directory AND disk density before you start copying the diskette. One of them is Diskcopy from TurboDOS XL/XE.........

Can you share some more sectorcopy programs with this functionality? - DIR show and disk density BEFORE starting copying. Supporting more than 4 drives is preferable, but this is not critical for an "archiving station". Disks greater than D4 on AspeQT/RespeQt can be used for work and contain some programs necessary for checking disks and other things.

And if you know - MyDos 4.55 is still in beta?

 

Today I try to check process with TurboDOS if I find a full working copy with utilities.

[MVladimir]

6 hours ago, Ely said:

I'm curious, is there a program that can detect what format a floppy is? I've got quite a few disks were I'm not sure what they are.

If I find in my collection a floppy disk with BASIC programs written by myself, I will try to publish the part of the listing containing a simple definition of density. As far as I remember, we used this when we wrote the DIR print program for floppy inserts a lot years ago.

[TZJB]

On 4/3/2023 at 9:48 PM, SlagOMatic said:

 

I'm using CopyMate 4.4 which I downloaded from the TOSEC archive on archive.org.

 

https://archive.org/details/Atari_8_bit_TOSEC_2012_04_23

     6428  2013-02-28 02:48   Atari 8 bit [TOSEC]/Applications/[ATR] (TOSEC-v2011-08-24_CM)/Copymate v4.4 (1987)(Palmer, Mike - Hillery, R.)(US).zip

It definitely sees drives higher than 4. If I have D1,D3-D8 mounted in FujiNet and D2 as the physical drive I'm able to rotate through all eight drives as either the source or destination, and I'm able to write to D5 without issues.

 

I have tried Copymate 4.4 from this archive and this now does indeed allow source and destination drive selection of D1 - D8. It seems to detect the disk drives when it boots and although I previously had disk images in all of the Fujinet drives it did not see them at first boot. Disk Directory selection still remains D1 - D2 however and it cannot read SpartaDOS disk directories.

 

While writing this I just tried booting Copymate 4.4 again after ejecting every other disk image in the Fujinet menu leaving D1, D2 physical 1050, D4, D6 and D8 . I am back to just D1 - D2 for source and desination drives so I think I am going to try AspeQT for virtual drive support on my laptop as I have now spent most of the day playing about with this. I am not sure if it's the Fujinet or Copymate that is giving me inconsistencies.

Edited April 5, 2023 by TZJB

[+Stephen]

I very much prefer Copy 2000 (V2.41D) by M. Karmeyer and K. Peters, 1992.  It has multi drive support, auto density detection, uses expanded RAM so therefore can copy a full double density disk in one pass even on a single drive machine.

[+CharlieChaplin]

More A8 disk and sector copy programs ? Alright then... 

 

- for the LDW drive (Indus compatible) there is:

a) Trackcopy for LDW: http://www.atarionline.pl/v01/index.php?ct=utils&sub=6. Stacja dyskietek&tg=Track Copier Turbo Drive LDW#Track Copier Turbo Drive LDW

b) Turbo Drive LDW 2000 copy: http://www.atarionline.pl/v01/index.php?ct=utils&sub=6. Stacja dyskietek&tg=Turbo Drive LDW 2000#Turbo Drive LDW 2000

c) Synchromesh Copy by Our 5oft (attached here)

Guess the LDW drive and its diskettes require sector interleave for highest speed (68kBaud), so you may have to format your disk that way first or the copy programs will not be that fast - only guessing, since I do not own any Indus or LDW drives...

 

other copy programs with disk directory option:

- Mycopier 2.1 supports directory for drives 1 and 2 but afaik, does not display the disk density then

- Diskcopy by Jaku-B (DiskCop1.ATR) can display a directory, but does not display the disk density then

- the older version of Diskcopy (from TurboDOS, DiskCOP2.ATR) displays the directory and disk density, but works only with 1 drive

- Diskworker displays a directory, but does not display the disk density then; works only with 1 drive;

- Fastcopy 2.01 has a DIR option, but does not display the disk density then; beware: format option will format the disk without query!

 

copy programs with density option:

- MILF: can read source/dest. drive config and display it in sectors and bytes; has an option to copy sectors;

 

Synchromesh_Copy.zip SectorCopy_Pgms.zip

[+CharlieChaplin]

2 hours ago, MVladimir said:

And if you know - MyDos 4.55 is still in beta?

 

Today I try to check process with TurboDOS if I find a full working copy with utilities.

 

Yes, MyDOS 4.55 is still beta and will not change its status anyway soon I guess.

 

TurboDOS XL/XE V2.1 with utilities can be found here: http://mrbacardi.000space.com/tools/tools.html

or here: https://atari.fox-1.nl/?s=Turbo+DOS

[+CharlieChaplin]

There is also a nice tool named "Percom Service", originally by C.Strotmann, updated last year by E.Puetz. Think it was written in Action! language. It can test the configuration of a disk / disk drive, format a diskette in various formats and verify a formatted disk. The only option missing there is the option "C" - copy diskette 

 

And errrmmm, it allows a few A8 formats that do not make much sense in my eyes, e.g. single density/double-sided, 80-tracks/single-sided, high density/single sided; think it would be better if the format menu would simply display 6 options: 1) 90k, 2) 130k, 3) 180k, 4) 360k, 5) 720k, 6) 1440k or with names such as 1) single, 2) medium, 3) double, 4) quad or dsdd 40, 5) octa or dsdd 80 and 6) high. A "copy diskette" option with XRAM support would be the icing on the cake there...

 

 

 

PERCOM.xex

[SlagOMatic]

I know this topic has changed into a discussion about copy software.  🙂  Based on feedback I've gotten here's my revised plan which I've been using for a couple of days now.

 

I started by booting into FujiNet, connecting to my local server, and creating three blank ATR images there -- 90K, 130K, and 180K, as that represents 100% of my floppy library. I then moved to my iMac, mounted my server, and duplicated those blank images in sufficient quantities to match what I'm copying at that moment. I then renamed the images to match the flopppy names. Then I go into the FujiNet web interface. I mount CopyMate XE from my local server as D1, leave D2 blank, and mount two disk images into D3 and D4.

 

Back on the Atari I reboot, getting into CopyMate XE. Put my source disk in D2. Select D2 as the source, D3 as the destination, and let it copy. When it's done flip the disk over in D2, change the destination to D4, and let it copy again.

 

When it's done, go back to the iMac and FujiNet web interface. Eject D3 and D4, mount the next set of disk images in D3 and D4. Go back to the Atari and repeat with the next disk. If I need more disk images then I just duplicate and rename a blank image as needed.

 

I also randomly check some of my disk images on the Atari emulator on my iMac. It's definitely weird to see this under emulation. It also gives me a much more vivid picture of how different the color palette is between the native Atari computer and the emulator.

 

The only thing that would make this smoother is if I could use D3-D8 as that would allow me to copy three disks (both sides) in one sitting, rather than one disk (both sides) in one sitting. But CopyMate XE doesn't see anything past D4.

 

I don't really need anything to tell me what density my media is. Anything that's a full disk image has to be single density since AFAIK all Atari disk software shipped on single density disks. My "compilation" disks are marked "SS/SD" or "SS/ED" or "SS/DD" on the label when I created them. All of my "tool" disks (e.g., the telecom disk that I used when I was BBSing on POTS lines) are SS/DD. The only thing that's variable are the different DOS disks I have, and since that's only like five or six disks it's no big deal to manually check them.

[_The Doctor__]

not all commercial disks were single density

[TZJB]

30 minutes ago, SlagOMatic said:

I know this topic has changed into a discussion about copy software.  🙂  Based on feedback I've gotten here's my revised plan which I've been using for a couple of days now.

 

I started by booting into FujiNet, connecting to my local server, and creating three blank ATR images there -- 90K, 130K, and 180K, as that represents 100% of my floppy library. I then moved to my iMac, mounted my server, and duplicated those blank images in sufficient quantities to match what I'm copying at that moment. I then renamed the images to match the flopppy names. Then I go into the FujiNet web interface. I mount CopyMate XE from my local server as D1, leave D2 blank, and mount two disk images into D3 and D4.

 

Back on the Atari I reboot, getting into CopyMate XE. Put my source disk in D2. Select D2 as the source, D3 as the destination, and let it copy. When it's done flip the disk over in D2, change the destination to D4, and let it copy again.

 

When it's done, go back to the iMac and FujiNet web interface. Eject D3 and D4, mount the next set of disk images in D3 and D4. Go back to the Atari and repeat with the next disk. If I need more disk images then I just duplicate and rename a blank image as needed.

 

I also randomly check some of my disk images on the Atari emulator on my iMac. It's definitely weird to see this under emulation. It also gives me a much more vivid picture of how different the color palette is between the native Atari computer and the emulator.

 

The only thing that would make this smoother is if I could use D3-D8 as that would allow me to copy three disks (both sides) in one sitting, rather than one disk (both sides) in one sitting. But CopyMate XE doesn't see anything past D4.

 

I don't really need anything to tell me what density my media is. Anything that's a full disk image has to be single density since AFAIK all Atari disk software shipped on single density disks. My "compilation" disks are marked "SS/SD" or "SS/ED" or "SS/DD" on the label when I created them. All of my "tool" disks (e.g., the telecom disk that I used when I was BBSing on POTS lines) are SS/DD. The only thing that's variable are the different DOS disks I have, and since that's only like five or six disks it's no big deal to manually check them.

 

Copy software discussion? Just a bit but it seemed important. Your methods seem sound and Copymate XE uses the extra Atari memory if you have it so you have nailed it.

 

Incidentally Copymate 4.4, which is a completely different program, is a pain as it tries to detect what drives are active when it boots, and if they are not contiguous fails and defaults to the first two drives. I tried this with AspeQT and the results are the same as Fujinet. Is that why you abandoned it?

 

And what @_The Doctor__ said! 😉. Plus many commercial disks had various exotic protections.

Edited April 5, 2023 by TZJB

[SlagOMatic]

1 hour ago, TZJB said:

Copy software discussion? Just a bit but it seemed important. Your methods seem sound and Copymate XE uses the extra Atari memory if you have it so you have nailed it.

 

Incidentally Copymate 4.4, which is a completely different program, is a pain as it tries to detect what drives are active when it boots, and if they are not contiguous fails and defaults to the first two drives. I tried this with AspeQT and the results are the same as Fujinet. Is that why you abandoned it?

I'm not knocking the discussion; I just didn't expect there to be so many opinions out there.  🙂

 

It wasn't my intention to "abandon" 4.4. It was just easier to do so. I ran into a couple of enhanced density disks which 4.4 can't handle and it was mentioned earlier that XE can handle them, so I switched. At the time the intention was to switch to XE, copy my ED disks, then switch back to 4.4, but since XE works at least as well as 4.4 I didn't see any need to go back. If there was a version of CopyMate that did everything XE does plus can use D5-D8 I'd probably move to that.

[SlagOMatic]

1 hour ago, _The Doctor__ said:

not all commercial disks were single density

Now I'm curious. Literally 100% of the disks I have are SD. Copy protection schemes notwithstanding, what are some examples of commercial disks that weren't SD? I would imagine that SD is the preferred format as it can be read by 100% of the drives out there, whereas ED disks wouldn't be accessible on an 810 and DD disks wouldn't be accessible to either the 810 or 1050 which means the potential market is substantially smaller, limited to XF551 and some third-party drive owners.

[+CharlieChaplin]

9 minutes ago, SlagOMatic said:

Now I'm curious. Literally 100% of the disks I have are SD. Copy protection schemes notwithstanding, what are some examples of commercial disks that weren't SD? I would imagine that SD is the preferred format as it can be read by 100% of the drives out there, whereas ED disks wouldn't be accessible on an 810 and DD disks wouldn't be accessible to either the 810 or 1050 which means the potential market is substantially smaller, limited to XF551 and some third-party drive owners.

 

Most european A8 vendors used enhanced 130k format, e.g. KE-Soft, AMC-Verlag (with copy protection!), Power per Post, ANG and several others. If you want to copy e.g. the Lemmings-clone "The Brundles", it will not work with SD, since all 3 disksides are 130k. The european A8 PD-libraries also made heavy use of 130k disks.

[+SoulBuster]

OS/A+ and a word processor that I cannot remember off the top of my head.

 

[SlagOMatic]

1 hour ago, CharlieChaplin said:

Most european A8 vendors used enhanced 130k format, e.g. KE-Soft, AMC-Verlag (with copy protection!), Power per Post, ANG and several others. If you want to copy e.g. the Lemmings-clone "The Brundles", it will not work with SD, since all 3 disksides are 130k. The european A8 PD-libraries also made heavy use of 130k disks.

In my experience most Atari user groups of the day used ED disks to distribute PD/shareware titles, with some of them offering SD disks at a slightly higher cost. But I'm not talking about the distribution of PD software via user groups. I was thinking more in line of publishers like Electronic Arts, Origin, Infocom, and like that.

[+CharlieChaplin]

51 minutes ago, SlagOMatic said:

In my experience most Atari user groups of the day used ED disks to distribute PD/shareware titles, with some of them offering SD disks at a slightly higher cost. But I'm not talking about the distribution of PD software via user groups. I was thinking more in line of publishers like Electronic Arts, Origin, Infocom, and like that.

 

KE-Soft, AMC-Verlag, Power per Post, ANG and many other european vendors/publishers weren't user groups! They sold commercial A8 software and a lot of their commercial disks used enhanced density / 130k. AMC-Verlag even used copy-protection on most of these 130k disks... take a look at atarimania for some of their titles:

 

http://www.atarimania.com/list_games_atari-400-800-xl-xe-ke-soft_publisher_1272_8_G.html

http://www.atarimania.com/list_games_atari-400-800-xl-xe-amc-verlag_publisher_1072_8_G.html

http://www.atarimania.com/list_games_atari-400-800-xl-xe-secret-games_publisher_1679_8_G.html

http://www.atarimania.com/list_games_atari-400-800-xl-xe-re-software_publisher_1387_8_G.html

http://www.atarimania.com/list_games_atari-400-800-xl-xe-ppp_publisher_1366_8_G.html

http://www.atarimania.com/list_games_atari-400-800-xl-xe-ang-software_publisher_1080_8_G.html

 

[_The Doctor__]

Atari titles themselves were also put out MD/ED, I grabbed the first thing on the pile as we were last discussing XEP80, Silent Butler and Y2k at some point. The disk is indeed Enhanced Density.

[+CharlieChaplin]

Afair, DOS 2.5 also came on an enhanced density 130k formatted diskette; later they put out versions of DOS 2.5 on 90k formatted disks...  (unsure if they did the same with DOS 3).

 

[SlagOMatic]

46 minutes ago, CharlieChaplin said:

Afair, DOS 2.5 also came on an enhanced density 130k formatted diskette; later they put out versions of DOS 2.5 on 90k formatted disks...  (unsure if they did the same with DOS 3).

My OEM DOS 3 is on an ED disk -- but that, and the fact of 2.5 on ED, makes sense, since those OS's shipped with the 1050.

[SlagOMatic]

11 hours ago, TZJB said:

I am having similar problems to @SlagOMatic with Fujinet Web Config remote control of image selection such that I sometimes lose access to some or all Fujinet disks. I can't put my finger on the issue exactly but it seems to kick off when I change an image remotely.

I'm copying right now and one thing I just noticed that it's always D3 that has this issue. As I write this I just swapped images via the web interface. When I swapped D4 it took awhile but the Atari recognized the disk. But when I swapped D3 it also took awhile and the Atari didn't recognize the disk. I had to eject and re-mount it two or three times before the Atari recognized it. And if, instead of trying over and over again, I reboot the FujiNet and then reboot the Atari, the FujiNet interface (on the Atari) shows entirely different disks mounted than what the web interface says. Sometimes the web interface says D3 and D4 are mounted, while the Atari interface says only D3 or D4 is mounted -- and what's mounted on the Atari interface is different than what's mounted on the web interface.

 

I suddenly realized that when I'm done copying I'm going to have to go back and check every single disk image to ensure that things were written to the correct images. Not looking forward to that.

 

UPDATE

Okay, I looked fate in the eye and was slapped for it. Shortly after writing the above, D4 started having issues. So they're both randomly cranky. I played around a bit and discovered that when FujiNet takes awhile to mount a disk, ALL mounted disks momentarily go offline -- and if you happen to be actively writing to a mounted disk at this time, then all remaining mounted disks go offline PERMANENTLY (until you reboot FujiNet and the Atari). And when it comes back up, none of your previously-mounted disks show up in the drive slot list.

 

Example: I had CopyMate XE in D1, physical drive at D2, blank disk images in D3 and D4. I had copied a physical disk into D3. When it was complete, I flipped my physical disk over and started copying it to D4. While that was happening I ejected the D3 image (via the web interface), then mounted a new image into D3. FujiNet showed that delay while mounting D3 and immediately my Atari started making that "grumbling" noise and then threw up a write error -- just like it makes if you eject a physical disk in mid-write. Pressing START to try again brings up the same error. I tried re-mounting the images in D3 and D4. Both showed that delay, ultimately telling me it was successful and showing up in the FujiNet web interface, but CopyMate still didn't see it and continued to generate the error. Cold-booting my Atari did NOT boot from FujiNet, instead bringing me to Self-Test (w/OPTION). I rebooted FujiNet, then the Atari, and booted into FujiNet. All of my drive slots were empty except for CopyMate in D1. It "feels" like some kind of memory leak. When the FujiNet is rebooted I almost never have that "delay when mounting" issue, but the longer I swap virtual disks the more it crops up, and apparently if I do it too much the whole FujiNet needs to be rebooted.

Edited April 6, 2023 by SlagOMatic

[_The Doctor__]

47 minutes ago, SlagOMatic said:

I'm copying right now and one thing I just noticed that it's always D3 that has this issue. As I write this I just swapped images via the web interface. When I swapped D4 it took awhile but the Atari recognized the disk. But when I swapped D3 it also took awhile and the Atari didn't recognize the disk. I had to eject and re-mount it two or three times before the Atari recognized it. And if, instead of trying over and over again, I reboot the FujiNet and then reboot the Atari, the FujiNet interface (on the Atari) shows entirely different disks mounted than what the web interface says. Sometimes the web interface says D3 and D4 are mounted, while the Atari interface says only D3 or D4 is mounted -- and what's mounted on the Atari interface is different than what's mounted on the web interface.

 

I suddenly realized that when I'm done copying I'm going to have to go back and check every single disk image to ensure that things were written to the correct images. Not looking forward to that.

 

UPDATE

Okay, I looked fate in the eye and was slapped for it. Shortly after writing the above, D4 started having issues. So they're both randomly cranky. I played around a bit and discovered that when FujiNet takes awhile to mount a disk, ALL mounted disks momentarily go offline -- and if you happen to be actively writing to a mounted disk at this time, then all remaining mounted disks go offline PERMANENTLY (until you reboot FujiNet and the Atari). And when it comes back up, none of your previously-mounted disks show up in the drive slot list.

 

Example: I had CopyMate XE in D1, physical drive at D2, blank disk images in D3 and D4. I had copied a physical disk into D3. When it was complete, I flipped my physical disk over and started copying it to D4. While that was happening I ejected the D3 image (via the web interface), then mounted a new image into D3. FujiNet showed that delay while mounting D3 and immediately my Atari started making that "grumbling" noise and then threw up a write error -- just like it makes if you eject a physical disk in mid-write. Pressing START to try again brings up the same error. I tried re-mounting the images in D3 and D4. Both showed that delay, ultimately telling me it was successful and showing up in the FujiNet web interface, but CopyMate still didn't see it and continued to generate the error. Cold-booting my Atari did NOT boot from FujiNet, instead bringing me to Self-Test (w/OPTION). I rebooted FujiNet, then the Atari, and booted into FujiNet. All of my drive slots were empty except for CopyMate in D1. It "feels" like some kind of memory leak. When the FujiNet is rebooted I almost never have that "delay when mounting" issue, but the longer I swap virtual disks the more it crops up, and apparently if I do it too much the whole FujiNet needs to be rebooted.

and this takes us back to a schizophrenic FujiNet issue...

[TZJB]

On 4/5/2023 at 6:32 PM, CharlieChaplin said:

More A8 disk and sector copy programs ? Alright then... 

 

- for the LDW drive (Indus compatible) there is:

a) Trackcopy for LDW: http://www.atarionline.pl/v01/index.php?ct=utils&sub=6. Stacja dyskietek&tg=Track Copier Turbo Drive LDW#Track Copier Turbo Drive LDW

b) Turbo Drive LDW 2000 copy: http://www.atarionline.pl/v01/index.php?ct=utils&sub=6. Stacja dyskietek&tg=Turbo Drive LDW 2000#Turbo Drive LDW 2000

c) Synchromesh Copy by Our 5oft (attached here)

Guess the LDW drive and its diskettes require sector interleave for highest speed (68kBaud), so you may have to format your disk that way first or the copy programs will not be that fast - only guessing, since I do not own any Indus or LDW drives...

 

other copy programs with disk directory option:

- Mycopier 2.1 supports directory for drives 1 and 2 but afaik, does not display the disk density then

- Diskcopy by Jaku-B (DiskCop1.ATR) can display a directory, but does not display the disk density then

- the older version of Diskcopy (from TurboDOS, DiskCOP2.ATR) displays the directory and disk density, but works only with 1 drive

- Diskworker displays a directory, but does not display the disk density then; works only with 1 drive;

- Fastcopy 2.01 has a DIR option, but does not display the disk density then; beware: format option will format the disk without query!

 

copy programs with density option:

- MILF: can read source/dest. drive config and display it in sectors and bytes; has an option to copy sectors;

 

Synchromesh_Copy.zip 9.11 kB · 2 downloads SectorCopy_Pgms.zip 488.81 kB · 5 downloads

 

Thank you for all your hard work regarding this topic.

 

So far only DISKCOPY3 seems to have a suitable density indicator/directory function for D1 to D4. Although disk directory doesn't show for SpartaDOS even when loaded from SpartaDOS, disk density IS indicated. This is the way.

 

[TZJB]

15 hours ago, SlagOMatic said:

I'm copying right now and one thing I just noticed that it's always D3 that has this issue. As I write this I just swapped images via the web interface. When I swapped D4 it took awhile but the Atari recognized the disk. But when I swapped D3 it also took awhile and the Atari didn't recognize the disk. I had to eject and re-mount it two or three times before the Atari recognized it. And if, instead of trying over and over again, I reboot the FujiNet and then reboot the Atari, the FujiNet interface (on the Atari) shows entirely different disks mounted than what the web interface says. Sometimes the web interface says D3 and D4 are mounted, while the Atari interface says only D3 or D4 is mounted -- and what's mounted on the Atari interface is different than what's mounted on the web interface.

 

I suddenly realized that when I'm done copying I'm going to have to go back and check every single disk image to ensure that things were written to the correct images. Not looking forward to that.

 

UPDATE

Okay, I looked fate in the eye and was slapped for it. Shortly after writing the above, D4 started having issues. So they're both randomly cranky. I played around a bit and discovered that when FujiNet takes awhile to mount a disk, ALL mounted disks momentarily go offline -- and if you happen to be actively writing to a mounted disk at this time, then all remaining mounted disks go offline PERMANENTLY (until you reboot FujiNet and the Atari). And when it comes back up, none of your previously-mounted disks show up in the drive slot list.

 

Example: I had CopyMate XE in D1, physical drive at D2, blank disk images in D3 and D4. I had copied a physical disk into D3. When it was complete, I flipped my physical disk over and started copying it to D4. While that was happening I ejected the D3 image (via the web interface), then mounted a new image into D3. FujiNet showed that delay while mounting D3 and immediately my Atari started making that "grumbling" noise and then threw up a write error -- just like it makes if you eject a physical disk in mid-write. Pressing START to try again brings up the same error. I tried re-mounting the images in D3 and D4. Both showed that delay, ultimately telling me it was successful and showing up in the FujiNet web interface, but CopyMate still didn't see it and continued to generate the error. Cold-booting my Atari did NOT boot from FujiNet, instead bringing me to Self-Test (w/OPTION). I rebooted FujiNet, then the Atari, and booted into FujiNet. All of my drive slots were empty except for CopyMate in D1. It "feels" like some kind of memory leak. When the FujiNet is rebooted I almost never have that "delay when mounting" issue, but the longer I swap virtual disks the more it crops up, and apparently if I do it too much the whole FujiNet needs to be rebooted.

 

Aha! Thank you @SlagOMatic for documenting this as it may prove that it's not just me. I do feel your pain as you will now probably need to check and verify every copy image.

 

I am running the most recent firmware on my Fujinet 1.6 which is definitely suspect too. This is one reason I am now experimenting with a laptop copy solution like @MVladimir is. I can duplicate disks and check them in Altirra on the same machine. They can still be saved on the Fujinet TNFS shared folder just by using a Samba share.

 

Could you possibly run the Fujinet Flasher in monitor mode and capture the output for clues as to what might be going wrong? A bug report needs to be submitted for this to be fixed https://fujinet.online/support/ and the support threads are here on AtariAge it seems.

 

All of my Atari hardware is going into storage again for Easter but I should be able to pick this up again in about a week.

 

 

[SlagOMatic]

4 hours ago, TZJB said:

Aha! Thank you @SlagOMatic for documenting this as it may prove that it's not just me. I do feel your pain as you will now probably need to check and verify every copy image.

Actually, I may not have to. In working through this I made a helpful discovery.

 

I made a single blank ATR file that I just duplicate <x> times so each file has the same date/time stamp. When CopyMate finishes writing to the mounted file the date/time changes to the current date/time. So even if FujiNet was having issues, I'd know if it wrote to the correct file because the date/time stamp for the files I'm currently using would be in ascending order. So far, every one of my images' date/time stamps are in proper ascending order by date which tells me that all of them are in the right place. Of course, there's also the possibility that the image data is corrupt which means I'd have to test them all anyway, but that's perhaps a separate thing.

 

Yes, I'm running the current firmware. In fact I just updated it a few days ago, just after I started copying all my disks in earnest.

 

I'm going to copy some more disks tonight so I'll capture the output as I go.

[TZJB]

13 hours ago, SlagOMatic said:

Actually, I may not have to. In working through this I made a helpful discovery.

 

I made a single blank ATR file that I just duplicate <x> times so each file has the same date/time stamp. When CopyMate finishes writing to the mounted file the date/time changes to the current date/time. So even if FujiNet was having issues, I'd know if it wrote to the correct file because the date/time stamp for the files I'm currently using would be in ascending order. So far, every one of my images' date/time stamps are in proper ascending order by date which tells me that all of them are in the right place. Of course, there's also the possibility that the image data is corrupt which means I'd have to test them all anyway, but that's perhaps a separate thing.

 

Yes, I'm running the current firmware. In fact I just updated it a few days ago, just after I started copying all my disks in earnest.

 

I'm going to copy some more disks tonight so I'll capture the output as I go.

 

Regarding the update to the file time/date stamp sounds a promising discovery. Did you copy with write verify?

 

I also duplicate blank ATRs on the PC, it's much easier than creating a new one from anywhere else.

 

I would be interested in any anomalies thrown up in the Fujinet Flasher debug output.