ATRFS: Mount ATR files as local directories under Linux or Mac

[beqelessen]

2 hours ago, flashjazzcat said:

Of course, I was able to ask questions about anything I didn't understand.

You make @pcrow's point. No documentation is perfect. Each of us have different experience and different gaps in our knowledge. No author can account for all that.

[pcrow]

1 hour ago, beqelessen said:

You make @pcrow's point. No documentation is perfect. Each of us have different experience and different gaps in our knowledge. No author can account for all that.

Yup.  It is quite detailed.  I shouldn't have said it the way I did.  The issue is that there are ambiguities, particularly when it comes to dealing with smaller sectors with the different encoding options, as well as the floppy drawer option (which others have said isn't widely used).

[flashjazzcat]

Agreed - it was simply the use of the word 'poor' which seemed inappropriate when applied to one of Konrad's efforts.

[pcrow]

1 minute ago, flashjazzcat said:

Agreed - it was simply the use of the word 'poor' which seemed inappropriate when applied to one of Konrad's efforts.

Yup.  I've updated the entry to say "had ambiguities."  I'm glad it was pointed out so that I could fix it.

[_The Doctor__]

The questions that were asked might be the things to add or edit in the work. If it helped one it may help many.

[drac030]

In fact, @flashjazzcat is one of the main authors of this specification.

 

Yes, it was I who wrote it, but it was preceded by a quite lengthy discussion on PM among several people who had been invited to discuss the details. That was the phase of the theory, and later it was implemented in practice, i.e. in SIDE/U1MB and IDE+ (this is why there is data interchangeability between these two interfaces). Also, @flashjazzcat wrote his FDISK according to all these specifications.

 

The phase of "asking questions" which was mentioned above was, I believe, the implementation phase, where we were clarifying any details which seemed vague then. It also resulted in multiple revisions of the text, as you can see in the PDF, the document underwent about 20 revisions.

 

So I am genuinely curious what can be ambiguous there after all this process.

[beqelessen]

@pcrow I'll get back to you in a later message here on your two blog posts. I think they're excellent.

 

Here's a very satisfactory use case for atrfs. I'm recovering BASIC programs from all of my Atari 410 cassette tapes I'd digitised last year sometime. atrfs is a vital part of the workflow.

 

(Forgive me if much of this is obvious to folks on here who've been computing with 8-bits more or less continuously since they were state of the art!)

 

On my Linux machine, I used mkatr to create an ATR file.

 

I've got Altirra (running in Wine on the same machine) configured to mount that ATR file into the emulated Atari. In turn, the ATR file is mounted on the Linux filesystem using atrfs at a directory named shared. I'm simultaneously sharing that same directory via TNFS, allowing me to have the same ATR mounted via FujiNet on my real Atari 800, which is running Sparta DOS X.

 

On Linux, using Audacity, I'm selecting saved programs by eye from the digitised tape audio and saving them off as WAV files, which I can mount as cassettes on Altirra. I CLOAD the data into Altirra (mostly successfully; fifteen year old me was sometimes a bit negligent in resetting the tape counter or cueing the tape properly when lining up a stretch of empty tape on which to save the next effort) and then SAVE to the ATR file.

 

As was good practice back in the day, you'd dump any program you'd written to cassette at least twice, to improve your chances of being able to load it again. I'm recovering all the copies, but I need to compare them to check that they're not actually different versions. As well as SAVEing the programs from Altirra, I'm LISTing them to disk as well, so in the Linux world I can use a bit of shell magic to compare any two LISTed files:

 

meld <(sed -e 's/\x9B/\n/g' shared/L_CHQ1.BAS) <(sed -e 's/\x9B/\n/g' shared/L_CHQ2.BAS)

 

I'm invoking the graphical diff tool Meld and using process substitution to non-destructively change Atari line endings to Linux line endings on the two LISTed files, and presenting that to Meld for comparison. Works a treat.

 

Once I know what's what, I can use my real Atari 800 to rename the files to something more meaningful and then copy them to the hard disk on the CF in INCOGNITO.

 

[pcrow]

1 minute ago, drac030 said:

In fact, @flashjazzcat is one of the main authors of this specification.

 

Yes, it was I who wrote it, but it was preceded by a quite lengthy discussion on PM among several people who had been invited to discuss the details. That was the phase of the theory, and later it was implemented in practice, i.e. in SIDE/U1MB and IDE+ (this is why there is data interchangeability between these two interfaces). Also, @flashjazzcat wrote his FDISK according to all these specifications.

 

The phase of "asking questions" which was mentioned above was, I believe, the implementation phase, where we were clarifying any details which seemed vague then. It also resulted in multiple revisions of the text, as you can see in the PDF, the document underwent about 20 revisions.

 

So I am genuinely curious what can be ambiguous there after all this process.

I wording on encoding 128-byte sectors is confusing, and it looks almost like it was put in as an afterthought.  I found the portion on 256-byte sectors to be a bit confusing.  What would be ideal would be a diagram or chart showing the first four bytes of the 512-byte sector and how they're mapped under each encoding option.  Alternatively, for each encoding option, show the mapping for the first two bytes of each logical sector to the 512-byte sector on each encoding method.  Interestingly, the examples I was given for 128-byte and 256-byte sectors had the bytes repeated instead of zeros in the ignored bytes, but I guess the implementation is free to do as it likes with the pad bytes if it's doing one logical sector to one physical sector.

 

Also, with the floppy drawer option, I didn't see any method for giving the separate disk images their own names.  If there is any such option, I missed it.

[flashjazzcat]

8 minutes ago, drac030 said:

Also, @flashjazzcat wrote his FDISK according to all these specifications.

BTW: I am still investigating the anomalous flags you told me about a few months back (being only recently up and running again after spending several months moving house).

[flashjazzcat]

9 minutes ago, pcrow said:

Interestingly, the examples I was given for 128-byte and 256-byte sectors had the bytes repeated instead of zeros in the ignored bytes, but I guess the implementation is free to do as it likes with the pad bytes if it's doing one logical sector to one physical sector.

Yes; this is simply for reasons of efficiency, since the driver must write to the data register 512 times regardless of the logical sector size, and rather than waste cycles/code space loading the accumulator with zero (or pre-loading an index register), the contents of the accumulator (i.e. the data) are just written to create the padding.

 

Having just read the section on padded and interleaved logical sectors again, I would suggest that the description is pragmatic rather than ambiguous. That's not to say that every reader will find the description easy to disseminate (I didn't initially), nor that diagrams would not be an aid to clarity, I suppose.

 

As for floppy drawers: that's simply not worth worrying about, I guess, since they were never used owing to the fact that floppy images were actually implemented as entities in the host file system.

Edited February 5 by flashjazzcat

[beqelessen]

@pcrow here's an ATR file, initially created with mkatr and stuffed full of recovered BASIC programs until I got the following error from Atari BASIC while attempting to LIST a long BASIC program to the almost-full disk, from Altirra:

 

ERROR-   162 AT LINE 1005

 

On Linux, I umounted the full ATR, copied it to a new directory, and then attempted to mount the copy on a new mount point (with the intent to delete the contents using Sparta DOS X.). I got the following warning on attempting to mount the ATR:

 

Unable to determine file system type; expose raw non-zero sectors

 

That mounts as follows:

 

$ ls -la
total 4
dr-xr-xr-x 1 ben ben    0 Feb  5 15:36 .
drwxrwxr-x 3 ben ben 4096 Feb  5 15:36 ..
-r--r--r-- 1 ben ben  252 Feb  5 15:36 .bootinfo
-rw-rw-r-- 1 ben ben  384 Feb  5 15:36 .bootsectors
-r--r--r-- 1 ben ben   92 Feb  5 15:36 .fsinfo
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector005
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector006
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector007
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector008
<snip>
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector717
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector718
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector719
-rw-rw-r-- 1 ben ben  128 Feb  5 15:36 .sector720
-rw-rw-r-- 1 ben ben    0 Feb  5 15:36 UNKNOWN_DISK_FORMAT
-rw-rw-r-- 1 ben ben    0 Feb  5 15:36 USE_.sector#_for_raw_nonzero_sectors

 

Here's the offending ATR file! (The BASIC files are all juvenile nonsense and not worth paying attention to.)

shared.atr

[pcrow]

10 hours ago, beqelessen said:

Here's the offending ATR file! (The BASIC files are all juvenile nonsense and not worth paying attention to.)

I just pushed a fix.  There was a bug in my SpartaDOS sanity that was failing when the disk was full.  Thanks for finding and reporting this.

[drac030]

On 2/5/2024 at 5:00 PM, flashjazzcat said:

BTW: I am still investigating the anomalous flags you told me about a few months back (being only recently up and running again after spending several months moving house).

It looks like the (or a) fix was already posted here: http://www.atari.org.pl/forum/viewtopic.php?pid=291400#p291400

 

So it just may be a question of preparing a final revision and putting it at the URL where the SDX build scripts are fetching it from.

 

As about the APT specs, if a section is ambiguous, one can always make a suggestion on how to rephrase (I am probably opening a can of worms here).

Edited February 6 by drac030

[_The Doctor__]

Don't let the worms out! Herding cats is also not recommended!

[flashjazzcat]

37 minutes ago, drac030 said:

It looks like the (or a) fix was already posted here: http://www.atari.org.pl/forum/viewtopic.php?pid=291400#p291400

 

So it just may be a question of preparing a final revision and putting it at the URL where the SDX build scripts are fetching it from.

Nice - thanks for letting me know. As for the build URL: thanks for reminding me about that, since it's probably some time since I remembered to update it.

[pcrow]

1 hour ago, drac030 said:

As about the APT specs, if a section is ambiguous, one can always make a suggestion on how to rephrase (I am probably opening a can of worms here).

I sent a private message.

 

I've found time and again, it's almost impossible to get a specification so that different programmers will interpret it the same way.  This was driven home back in my computer networking class, where we had a project to write a token ring network.  We had three groups, and we were each supposed to run our own code on one of three computers, each with two serial cables making a three-node ring.  We started by writing a specification as a class, and it was a solid document, but then of course our implementations weren't compatible, so we had to decide on one as the de facto standard and make the others match it's interpretation.

[_The Doctor__]

Just include the changes as an additional note, or another way to look at blah blah. Why replace stuff, when it can supplement or be an example.

Edited February 6 by _The Doctor__

[beqelessen]

1 hour ago, pcrow said:

I sent a private message.

 

I've found time and again, it's almost impossible to get a specification so that different programmers will interpret it the same way.  This was driven home back in my computer networking class, where we had a project to write a token ring network.  We had three groups, and we were each supposed to run our own code on one of three computers, each with two serial cables making a three-node ring.  We started by writing a specification as a class, and it was a solid document, but then of course our implementations weren't compatible, so we had to decide on one as the de facto standard and make the others match it's interpretation.

That's how the IETF functions, isn't it? "Rough consensus and running code."

 

https://courses.cs.duke.edu/common/compsci092/papers/govern/consensus.pdf

[woj]

@pcrow I finally got to checking out the new version. First, the segfault I get, this is the best I can do, I really never used gdb before:

 

(gdb) r --create --fs=dos25 --name=test.atr test
Starting program: /home/woj/atari/atrfs --create --fs=dos25 --name=test.atr test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000055555555eb16 in ?? ()
(gdb) 

 

Second, mounting the APT SD image I have sent you earlier for tests, you did say there is something off with the being file truncated, however:

 

ATP partition says it runs through sector 131136 which is past the end of the file
ATP partition adjusted to 65471 sectors

 

This seems to me like the numbers are off by the factor of 2, something to do with the sector size confusion?

 

And, BTW, "APT" probably, not "ATP"  

[invisible kid]

A segfault will generate a core dump file unless there is a configuration set to not produce one. Then you can open the core file with gdb and it will show a trace of what code it went through and the crashpoint. You can also command gdb to create a core file manually. This page is for a specific distro, but the information looks general. https://wiki.archlinux.org/title/Core_dump

 

https://stackoverflow.com/questions/5115613/core-dump-file-analysis

Edited February 12 by invisible kid

[sanny]

If you are at the gdb prompt after the SIGSEGV, type "bt" (for backtrace) to see the call history.

If you don't see anything sensible (just '??' etc), compile the program with debug information and without optimizations (with gcc: '-ggdb -O0').

[woj]

Thanks! Interesting, because I did not recompile it, but now that I ran it, there was more information right away after the segfault, and with bt there is some more:

 

(gdb) r --create --fs=dos25 --name=test.atr test
Starting program: /home/woj/bin/atrfs --create --fs=dos25 --name=test.atr test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000055555555eb16 in mydos_bitmap (atrfs=0x5555555a60c0 <master_atrfs>, sector=48, allocate=0) at mydos.c:989
989	         map[sec_bitmap/8] |= mask; // Set to one (free)
(gdb) bt
#0  0x000055555555eb16 in mydos_bitmap (atrfs=0x5555555a60c0 <master_atrfs>, sector=48, allocate=0) at mydos.c:989
#1  0x000055555555eb7e in mydos_free_sector (atrfs=0x5555555a60c0 <master_atrfs>, sector=48) at mydos.c:1004
#2  0x0000555555563868 in mydos_newfs (atrfs=0x5555555a60c0 <master_atrfs>) at mydos.c:2176
#3  0x0000555555557e20 in atr_preinit () at atrfs.c:229
#4  0x00005555555598c2 in main (argc=5, argv=0x7fffffffdf38) at atrfs.c:769

 

[invisible kid]

mydos.c:989

 

         map[sec_bitmap/8] |= mask; // Set to one (free)

[SteveB]

Any chance of a binary x64 release for the gcc shy people?

 

[beqelessen]

3 minutes ago, SteveB said:

Any chance of a binary x64 release for the gcc shy people?

 

Here you go! Built on 64-bit Ubuntu 22.04.

atrfs